Rewriting: domain literals

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.a The rightmost 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/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/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@&#x5b;128.6.3.40&#x5d; is to be rewritten. The rewriter looks for &#x5b;128.6.3.40&#x5d;, then &#x5b;128.6.3.&#x5d;, then &#x5b;128.6.&#x5d;, then &#x5b;128.&#x5d;, then &#x5b;&#x5d;, then &#x5b;&#x2a;.&#x2a;.&#x2a;.&#x2a;&#x5d;, and finally the match-all rule  ".".

When domain literals are combined with domain names the number of lookup attempts gets to be quite large. This is not normal usage and its use is strongly discouraged. For example, the address dan@&#x5b;1.2&#x5d;.a.&#x5b;3.4&#x5d;.b would generate requests for: &#x5b;1.2&#x5d;.a.&#x5b;3.4&#x5d;.b &#x5b;1.&#x5d;.a.&#x5b;3.4&#x5d;.b  &#x5b;&#x5d;.a.&#x5b;3.4&#x5d;.b  &#x5b;&#x2a;.&#x2a;&#x5d;.a.&#x5b;3.4&#x5d;.b  .a.&#x5b;3.4&#x5d;.b  &#x5b;&#x2a;.&#x2a;&#x5d;.&#x2a;.&#x5b;3.4&#x5d;.b  .&#x5b;3.4&#x5d;.b  &#x5b;&#x2a;.&#x2a;&#x5d;.&#x2a;.&#x5b;3.&#x5d;.b  .&#x5b;3.&#x5d;.b  &#x5b;&#x2a;.&#x2a;&#x5d;.&#x2a;.&#x5b;&#x5d;.b  .&#x5b;&#x5d;.b  &#x5b;&#x2a;.&#x2a;&#x5d;.&#x2a;.&#x5b;&#x2a;.&#x2a;&#x5d;.b  .b  &#x5b;&#x2a;.&#x2a;&#x5d;.&#x2a;.&#x5b;&#x2a;.&#x2a;&#x5d;.&#x2a; . New in MS 7.0, the MTA supports the RFC 2822 definition of spaces in domain literals as FWP, or in other words, semantically null; (note  that the meaning of such spaces had not been specified in RFC 822). That is, as of MS 7.0, the MTA will canonicalize   as ,  which would not have  occurred in previous versions.

aNote that the support of numeric         domain literals is not required by either the MTA or RFC 822. Their support is enabled by including IP literal rewrite rules in the MTA configuration.

See also:
 * Application of rewrite rules to addresses