PMDF System Manager's Guide


Previous Next Contents Index

2.2.3.2 Scanning the Rewrite Rules

Once the first host/domain specification has been extracted from the address, PMDF 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 (i.e., the left-hand side of each rule). The comparison is case insensitive. Case insensitivity is mandated by RFC 822, UUCP addresses notwithstanding. PMDF is insensitive to case but preserves it whenever possible.

If the host/domain specification does not match any pattern, in which case it is said to "not match any rule", the first part of the host/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/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 only done 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/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 somewhat more algorithmic view of this matching procedure is given below.

  1. The host/domain specification is used as the initial value for the comparison strings spec_1 and spec_2. E.g., spec_1 = spec_2 = a.b.c).
  2. 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.
  3. If no match is found then the leftmost, non-asterisk part of spec_2 is converted to an asterisk. E.g., 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; etc. The resulting comparison string spec_2 is compared with only the configuration file. The domain database is not consulted. The matching procedure is exited if a match is found.
  4. If no match is found then the first part, including any leading period, of the comparison string spec_1 is removed. In the case where spec_1 has only one part (e.g., .c or c), the string is replaced with a single period, ".". If the resulting string spec_1 is of non-zero length, then we return to Step 1. If the resulting string has zero length (i.e., was previously ".") then the lookup process has failed and we exit the matching procedure.

For example, suppose the address iris@sc.cs.example.com is to be rewritten. This causes the rewriter to look for the following patterns in the given order:
Pattern Files Scanned
sc.cs.example.com configuration file and then domain database
*.cs.example.com configuration file rules only
.cs.example.com configuration file and then domain database
*.*.example.com configuration file rules only
.example.com configuration file and then domain database
*.*.*.com configuration file rules only
.com configuration file and then domain database
*.*.*.* configuration file rules only
. match all rule described in Section 2.2.4.3

Note

Always remember that patterns involving asterisks are only searched for in the configuration file's set of rewrite rules; no searching is done for these patterns in the domain database.


Previous Next Contents Index