Sun Java System Messaging Server 6.3 Administration Guide

11.5 How the MTA Applies Rewrite Rules to an Address

The following steps describe how the MTA applies rewrite rules to a given address:

The MTA extracts the first host or domain specification from an address.

An address can specify more than one host or domain name as in the case:

jdoe%hostname@siroe.com.
After identifying the first host or domain name, the MTA conducts a search that scans for a rewrite rule whose pattern matches the host or domain name.
When the matching rewrite rule is found, the MTA rewrites the address according to the template portion of that rule.
Finally, the MTA compares the channel tag with the host names that are associated with each channel.

If a match is found, the MTA enqueues the message to the associated channel; otherwise, the rewrite process fails. If the matching channel is the local channel, some additional rewriting of the address may take place by looking up the alias database and alias file.

These steps are described in more detail in the subsections that follow.

Note –

Using a channel tag that does not belong to any existing channel will cause messages whose addresses match this rule to be bounced. That is, it makes the matching messages nonroutable.

This section consists of the following subsections:

11.5.1 Step 1. Extract the First Host or Domain Specification

The process of rewriting an address starts by extracting the first host or domain specification from the address. (Readers not familiar with RFC 822 address conventions are advised to read that standard to understand the following discussion.) The order in which host/domain specifications in the address are scanned is as follows:

Hosts in source routes (read from left to right)
Hosts appearing to the right of the “at” sign (@)
Hosts appearing to the right of the last single percent sign (%)
Hosts appearing to the left of the first exclamation point (!)

The order of the last two items is switched if the bangoverpercent keyword is in effect on the channel that is doing the address rewriting. That is, if the channel attempting to enqueue the message is, itself, marked with the bangoverpercent channel keyword.

Some examples of addresses and the host names that could be extracted first are shown in Table 11–3.

Table 11–3 Extracted Addresses and Host Names


Address	First Host Domain Specification	Comments
`user@a`	`a`	A “short-form” domain name.
`user@a.b.c`	`a.b.c`	A “fully qualified” domain name (FQDN).
`user@[0.1.2.3]`	`[0.1.2.3]`	A “domain literal.”
`@a:user@b.c.d`	`a`	Source-routed address with a short-form domain name, the “route.”
`@a.b.c:user@d.e.f`	`a.b.c`	Source-routed address; route part is fully qualified.
`@[0.1.2.3]:user@d.e.f`	`[0.1.2.3]`	Source-routed address; route part is a domain literal.
`@a,@b,@c:user@d.e.f`	`a`	Source-routed address with an a to b to c routing.
`@a,@[0.1.2.3]:user@b`	`a`	Source-routed address with a domain literal in the route part.
`user%A@B`	`B`	This nonstandard form of routing is called a “percent hack.”
`user%A`	`A`
`user%A%B`	`B`
`user%%A%B`	`B`
`A!user`	`A`	“Bang-style” addressing; commonly used for UUCP.
`A!user@B`	`B`
`A!user%B@C`	`C`
`A!user%B`	`B`	`nobangoverpercent` keyword active; the default.
`A!user%B`	`A`	`bangoverpercent` keyword active.

RFC 822 does not address the interpretation of exclamation points (!) and percent signs (%) in addresses. Percent signs are customarily interpreted in the same manner as at signs (@) if no at sign is present, so this convention is adopted by the Messaging Server MTA.

The special interpretation of repeated percent signs is used to allow percent signs as part of local user names; this might be useful in handling some foreign mail system addresses. The interpretation of exclamation points conforms to RFC 976’s “bang-style” address conventions and makes it possible to use UUCP addresses with the Messaging Server MTA.

The order of these interpretations is not specified by either RFC 822 or RFC 976, so the bangoverpercent and nobangoverpercent keywords can be used to control the order in which they are applied by the channel doing the rewriting. The default is more “standard,” although the alternate setting may be useful under some circumstances.

Note –

The use of exclamation points (!) or percent signs (%) in addresses is not recommended.

11.5.2 Step 2. Scan the Rewrite Rules

Once the first host or domain specification has been extracted from the address, the MTA consults the rewrite rules to find out what to do with it. The host/domain specification is compared with the pattern part of each rule (that is, the left side of each rule). The comparison is case insensitive. Case insensitivity is mandated by RFC 822. The MTA is insensitive to case but preserves it whenever possible.

If the host or domain specification does not match any pattern, in which case it is said to “not match any rule,” the first part of the host or domain specification—the part before the first period, usually the host name—is removed and replaced with an asterisk (*) and another attempt is made to locate the resulting host or domain specification, but only in the configuration file rewrite rules (the domain database is not consulted).

If this fails, the first part is removed and the process is repeated. If this also fails the next part is removed (usually a subdomain) and the rewriter tries again, first with asterisks and then without. All probes that contain asterisks are done only in the configuration file rewrite rules table; the domain database is not checked. This process proceeds until either a match is found or the entire host or domain specification is exhausted. The effect of this procedure is to try to match the most specific domain first, working outward to less specific and more general domains.

A more algorithmic view of this matching procedure is:

The host/domain specification is used as the initial value for the comparison strings spec_1 and spec_2. (For example, spec_1 = spec_2 = a.b.c).
The comparison string spec_1 is compared with the pattern part of each rewrite rule in the configuration file and then the domain database until a match is found. The matching procedure is exited if a match is found.
If no match is found, then the left-most, nonasterisk part of spec_2 is converted to an asterisk. For example, if spec_2 is a.b.c then it is changed to *.b.c; if spec_2 is *.b.c, then it is changed to *.*.c. The matching procedure is exited if a match is found.
If no match is found then the first part, including any leading period, of the comparison string spec_1 is removed. Where spec_1 has only one part (for example, .c or c), the string is replaced with a single period, “.”. If the resulting string spec_1 is of nonzero length, then you return to step 1. If the resulting string has zero length (for example, was previously “.”), then the lookup process has failed and you exit the matching procedure.

For example, suppose the address dan@sc.cs.siroe.edu is to be rewritten. This causes the MTA to look for the following patterns in the given order:

sc.cs.siroe.edu
*.cs.siroe.edu
.cs.siroe.edu
*.*.siroe.edu
.siroe.edu
*.*.*.edu
.edu
*.*.*.*
.

11.5.3 Step 3. Rewrite Address According to Template

Once the host/domain specification matches a rewrite rule, it is rewritten using the template part of the rule. The template specifies three things:

A new user name for the address.
A new host/domain specification for the address.
A channel tag that identifies an existing MTA channel to which messages to this address should be sent.

11.5.4 Step 4. Finish the Rewrite Process

One of two things can happen once the host/domain specification is rewritten.

If the channel tag is associated neither with the local channel nor a channel marked with the routelocal channel keyword, or there are no additional host/domain specifications in the address, the rewritten specification is substituted into the address replacing the original specification that was extracted for rewriting, and the rewriting process terminates.
If the channel tag matches the local channel or a channel marked routelocal and there are additional host/domain specifications that appear in the address, the rewritten address is discarded, the original (initial) host/domain specification is removed from the address, a new host/domain specification is extracted from the address, and the entire process is repeated. Rewriting will continue until either all the host/domain specifications are gone or a route through a non-local, non-routelocal channel is found. This iterative mechanism is how the MTA provides support for source routing. In effect, superfluous routes through the local system and routelocal systems are removed from addresses by this process.

11.5.5 Rewrite Rule Failure

If a host/domain specification fails to match any rewrite rule and no default rule is present, the MTA uses the specification “as-is”; for example, the original specification becomes both the new specification and the routing system. If the address has a nonsensical host/domain specification it will be detected when the routing system does not match any system name associated with any channel and the message will be bounced.

11.5.6 Syntax Checks After Rewrite

No additional syntax checking is done after the rewrite rules have been applied to an address. This is deliberate—it makes it possible for rewrite rules to be used to convert addresses into formats that do not conform to RFC 822. However, this also means that mistakes in the configuration file may result in messages leaving the MTA with incorrect or illegal addresses.

11.5.7 Handling Domain Literals

D domain literals are handled specially during the rewriting process. If a domain literal appearing in the domain portion of an address does not match a rewrite rule pattern as is, the literal is interpreted as a group of strings separated by periods and surrounded by square brackets. The right-most string is removed and the search is repeated. If this does not work, the next string is removed, and so on until only empty brackets are left. If the search for empty brackets fails, the entire domain literal is removed and rewriting proceeds with the next section of the domain address, if there is one. No asterisks are used in the internal processing of domain literals; when an entire domain literal is replaced by an asterisk, the number of asterisks corresponds to the number of elements in the domain literal.

Like normal domain or host specifications, domain literals are also tried in most specific to least specific order. The first rule whose pattern matches will be the one used to rewrite the host or domain specification. If there are two identical patterns in the rules list, the one which appears first will be used.

As an example, suppose the address dan@[128.6.3.40] is to be rewritten. The rewriter looks for [128.6.3.40], then [128.6.3.], then [128.6.], then [128.], then [], then [*.*.*.*], and finally the match-all rule “.”.