Rewriting: scanning for a domain match

Once the first host/domain specification has been extracted from the address, the MTA consults the rewrite rules to find out what to do with  it. Initially, the exact host/domain specification is compared with the pattern part of each rule  (i.e., the left-hand side of each  rule). This comparison is (and the rest of the comparisons discussed below are also) case insensitive. Case insensitivity is mandated by RFC 822, UUCP addresses notwithstanding. The MTA is insensitive to case but preserves it whenever possible.

As of MS 8.0.2.2, if A-labels (see RFC 5890 section 2.3.2.1) are present they are both looked up as-is and in U-label form. Similarly, if U-labels are present they are converted to A-labels, looked up, then converted back to U-labels and looked up. Finally, any U-labels specified on the left hand side of a rewrite rule are converted to A-labels and back again when the rewrite rules are loaded, so they will match even if they are specified in uncanonical and/or unnormalized formats.

If the pattern matches, then the host/domain is transformed as specified by the  rewrite rule template (right hand side). If that (transformed, as appropriate) host/domain specification then matches a  channel official host name,  the rewriting is considered complete and  the address is considered to match that channel.

New in Comms Suite 7.0 is support for attempting an initial, special rewrite of a host/domain with a trailing dot. (Such a trailing dot on a host/domain name is illegal in Internet domain names, but has been  tolerated in some contexts by the MTA for a long time.  RFC 1123 points out that trailing dots are syntactically illegal in email  but notes that some convention needs to exist in user interfaces where  short form names can be used. Accordingly, it may be handy in contexts  like SMTP submission of messages, SMTP SUBMIT, to be able to accept addresses with trailing dots,  and then remove the dot while attaching special semantics to its  initial presence.) New in 7.0, the MTA will attempt to rewrite the  host/domain with the trailing dot present; if that fails, then the MTA  will remove the trailing dot from the host/domain and then continue  rewriting attempts, as normal, from that point on with the trailing dot  removed.

As of MS 7.0U3, if the host/domain doesn&#x27;t match and is a domain literal of the form "&#x5b;channel:name&#x5d;", where "name" is the name of an existing channel, a rewrite rule of the form: &#x5b;channel:name&#x5d;       $U%$D@official-host-name where "official-host-name" is the official channel host associated with the channel "name", is synthesized and used. This channel name form for domain names is primarily intended for use in source routes.

If the host/domain specification does not match any pattern, in which case it is said to "not match any rule", then 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 regular rewrite rules (those in the    file or in Unified Configuration    group -- 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, as long as there is still at least one  portion of the original host/domain specification remaining. All probes that contain asterisks are only done in the regular rewrite  rules table (those rewrite rules in   or in the   group in Unified  Configuration); the domain database is not checked. This process proceeds until either a match is found or the host/domain specification up to  (but not including) its last portion 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.

If the entire host/domain specification with the exception of its last (right-most) portion has been exhausted looking for a rewrite rule  pattern that matches and a match has still not been found, then an  additional check of the entire host/domain specification is performed;  namely the channel host table is scanned for a matching host name  associated with a channel; that is, the entire host/domain  specification is compared against any channel  official host names and  host name aliases  on channel definitions to look for a mtach.

If a match has still not been found, then a special all-components-replaced-by-asterisks attempt is made, (in particular,  in the case of short-form host names an &#x2a; lookup is attempted) in the  regular rewrite rules (those in   or in the   group in Unified Configuration), see   Rules to match domains containing exact numbers of components; and if that did not succeed then  the special "match-all" rule described in  A_rule_to_match_any_address is  attempted.

A somewhat more algorithmic view of this matching procedure is given below.



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

 The comparison string spec_1 is compared with the pattern part of   each rewrite rule in the   configuration file (legacy  configuration) or the     group (Unified Configuration), 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 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 &#x2a;.b.c; if spec_2 is &#x2a;.b.c then it is changed to &#x2a;.&#x2a;.c;    etc. The resulting comparison string spec_2 is compared with    only the configuration file (legacy configuration) or   the   group (Unified   Configuration). The domain database is not   consulted. 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. 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 dan@sc.cs.cmu.edu is to be rewritten. This causes the rewriter to look for the following patterns in the given order:

Note: Always remember that patterns involving asterisks (except the initial match-all pattern, $&#x2a;) are only searched for  in the configuration file&#x27;s set of rewrite rules; no searching is done  for these patterns in the domain database.

See also:
 * Rewrite rule patterns and tags
 * Rewrite rule templates
 * official_host_name Option
 * local_host_alias Option
 * Initial match-all rule
 * Rules to match domains containing exact numbers of components
 * A rule to match any address
 * Application of rewrite rules to addresses