When a message enters an Internet Message Transfer Agent (IMTA) channel, it must be placed in the correct channel queue and subsequently routed to the correct destination for delivery. The domain rewriting rules (from this point forward called the "rewrite rules") are a tool that the IMTA uses to route messages to the correct host. Rewrite rules perform the following functions:
|
|
Extract the host/domain specification from an address of an incoming message |
|
|
Match the host/domain specification with a rewrite rule pattern |
|
|
Rewrite the host/domain specification based on the domain template |
|
|
Decide the IMTA channel queue in which the message should be placed |
The following sections walk you through the rewrite rule process. They also discuss the following elements of the rewrite rule itself:
|
|
Pattern - A string composed of ASCII characters that the host/domain specification can potentially match |
|
|
Domain template - A template that defines how the host/domain specification is rewritten |
|
|
Routing system - The destination channel |
|
|
Controls |
When a message enters a channel, all addresses on the envelope and in the message header are examined and the host/domain specification of the address is extracted. The host/domain specification is the part of the address that is to the right of the at (@) sign. For example, in the address john@corp.acme.com, corp.acme.com is the host/domain specification.
The channel scans for a match between the extracted host/domain specification and the pattern portion of the first rewrite rule in the list. (The channel scans the host/domain specification from left to right--for example, starting with corp, then acme, then com--and the rewrite rules list from top to bottom.) If a match is not found in the first rule, the channel scans the next rule and so on. If a match is found, the host/domain specification is rewritten per the domain template of the rewrite rule. If a match is not found, the message is returned to the sender.
TABLE 1-2 outlines the types of rewrite rule patterns that your rewrite rule list can potentially contain and the order in which each type of pattern is scanned when the input address is joe@sc.cs.cmu.edu.
TABLE 1-2 Rewrite Rule Pattern Types (listed in the order in which pattern is scanned).
*The example patterns shown in this column are not meant to imply that you can scan for patterns with a fixed number of address tokens.
Note - Your channel does not necessarily contain a rewrite rule and, subsequently, a rewrite rule pattern for each of the patterns described in TABLE 1-2. However, if your channel does contain a rewrite rule for each of the described patterns, then TABLE 1-2 outlines the default order in which each pattern is scanned for until a match is found. That is, whatever the order the rules are written, they are scanned from most specific to least specific.
The rewrite rule list for a channel can include multiple rewrite rules containing the same pattern but different domain templates. You can reconfigure the order of these types of rewrite rules so that the channel scans these rules in the reconfigured order. This features enables you to fine-tune the rewrite rule list with your preference as to how the domain/host specification in these types of rules is rewritten. You cannot reconfigure the basic order in which the rewrite rules in TABLE 1-2 are scanned.
To illustrate how the host/domain specification and rewrite rule matching process works, if the extracted host/domain specification is
zoo.cmu.edu
and the following patterns are defined in the rewrite rules:
eng.cmu.edu
*.cmu.edu
then a match would result after the second scan with *.cmu.edu.
For information on how to configure rewrite rules, refer to "Rewrite Rules" on page 132.
If a match is made between the host/domain specification of an address and the pattern portion of a rewrite rule, the host/domain specification is rewritten according to the domain template portion of the rewrite rule.
The domain template defines how the host/domain specification is rewritten. The template can be composed of one or a combination of the following elements:
|
|
A full static host/domain specification, for example, corp.acme.com, or a portion of a host/domain specification (a portion of the address tokens or elements set off by decimals), for example,.com. |
|
|
A single field substitution string that dynamically rewrites one address token of the host/domain specification represented by a wildcard character (*). The address token to be rewritten can be the portion of the address that did not match the rewrite rule pattern or the portion that matched the wildcard character. The rewriting of a host/domain specification is based on the contents of the specification itself. The template can include multiple field substitution strings. |
Note - The IMTA allows for many more field substitution strings. Refer to the SIMS Reference Manual for more information.
The syntax of the field substitution string is $&n.
where n is an integer from 0 to infinity. n represents the unmatched or wildcard address token that is to be rewritten. From left to right, the leftmost address token is represented by the integer 0; the second from the left is represented by the integer 1, and so on.
For example, imagine that a host/domain specification matches the following rewrite rule pattern:
*.*.com
The corresponding domain template consists of the following:
$&0.$&1.com
In this domain template, $&0 and $&1 are the field substitution strings and com is the static portion. As mentioned earlier in this section, an address is rewritten based on the contents of the host/domain specification itself. Using the same example, imagine that the incoming address is
john@corp.acme.com
The host/domain specification is rewritten as follows:
corp.acme.com
In this domain template, $&0 is rewritten as corp, and $&1 is rewritten as acme.The address tokens corp. and acme. were taken from the host/domain specification.
Although in this example, a three-token host/domain specification is rewritten as a three-token host/domain specification, this specification can be rewritten with any number of tokens desired. Using the same example, except with the domain template
finance.$&0.$&1.com
the incoming address john@corp.acme.com can be rewritten as john@finance.corp.acme.com.
Also note that the value of n in the field substitution string of the domain template must correspond to the number of unmatched or wildcard address tokens in the rewrite rule pattern.In the example used above, the string $&1 implies that there are two unmatched or wildcard address tokens in the rewrite rule pattern, as is the case (*.*.com).
If the value of n does not correspond to the number of unmatched or wildcard address tokens, for example, a string of $&1 exists in the domain template (implies two unmatched or wildcard address tokens) but the rewrite rule pattern contains only one unmatched or wildcard address token (*.acme.com), then the rewrite rule will not work. The host/domain specification will not be rewritten.
The last element of a host/domain rewrite rule is the routing system or destination channel in whose queue a message should be placed for delivery.
By default, a rewrite rule is scanned for all header and envelope addresses. It is possible to specify that a given rule applies to a subset of all the addresses. For example, a rule can search for some combination (AND) of the "To:" "From:" "CC:" and "Bcc:" header addresses and the envelope recipient addresses (RCPT TO). Additional filters (control sequences) are available and are documented in the SIMS Reference Manual.
During installation of SIMS, the system generates default rewrite rules for each of the installed channels. You can modify the default rewrite rules or add new rewrite rules for each of the installed channels using the Rewrite Rules section in the IMTA property book of the Administration Console.
When you create a new channel (applies to Sun Internet Mail Server - Enterprise Edition only), the system does not generate default rewrite rules. After you create the new channel, the Administration Console prompts you to add new rewrite rules.
For complete information on installing SIMS, refer to the SIMS Installation Guide. For information on creating a new channel, refer to "To Create a Channel" on page 120.
The Administration Console enables you to add a rewrite rule to an existing or newly created channel. It also enables you to delete or modify an existing rewrite rule associated with an existing channel. For more information on adding and reconfiguring the rewrite rules associated with a channel using the Administration Console, refer to "Rewrite Rules" on page 132.