Rewrite rule patterns and tags

Most rewrite rule patterns consist either of a specific host name that will match only and exactly that host, e.g., host.domain.com or consist of a subdomain pattern that will match any host/domain in the entire subdomain, e.g., .domain.com A rewrite rule pattern such as the above would match any host.domain.com or host.subnet.domain.com sort of host/domain name. Note, however, that it will not match the exact host name domain.com; to match the exact host name domain.com, a separate  domain.com pattern would be needed.

The matching in rewrite rule patterns is case-insensitive: uppercase and lowercase are not significant, in either the pattern, or in the domain of the address being rewritten. (Note, however, that rewrite rule templates preserve case.)

Since as discussed in Rewriting: scanning for a domain match  the MTA attempts to rewrite  host/domain names starting from the specific host name and then  incrementally generalizing the name to make it less specific, this  means that a more specific rewrite rule pattern will be preferentially  used over more general rewrite rule patterns. For instance, if the rewrite rule patterns hosta.subnet.domain.com .subnet.domain.com .domain.com are present in the configuration file (legacy configuration) or the  group (Unified Configuration),b then an address of  jdoe@hosta.subnet.domain.com will match the specific  hosta.subnet.domain.com rewrite rule pattern, while an address of  jdoe@hostb.subnet.domain.com will match the more general  .subnet.domain.com rewrite rule pattern, and an address of  jdoe@hostc.domain.com will match the .domain.com rewrite rule pattern.

In particular, the use of rewrite rules incorporating subdomain rewrite rule patterns is common for sites on the Internet. Such a site will typically have a number of rewrite rules for their own internal hosts  and subnets, and then will include rewrite rules for the top-level  Internet subdomains into their configuration: in older configuration,  from the file    stored in the MTA&#x27;s table (config)  directory, or in newer configurations from the   file.

In older configurations, the incorporation of rewrite rules from  such as  !    Ascension Island .AC                                    $U%$H$D@TCP-DAEMON ...&#x5b;text removed for brevity&#x5d;... !   Zimbabwe .ZW                                    $U%$H$D@TCP-DAEMON with rewrite rule patterns that match the top level Internet domains and rewrite rule templates that rewrite addresses  matching such patterns to an outgoing TCP/IP channel, ensure that  messages to Internet destinations (other than to the internal host  destinations handled via more specific rewrite rules) will be properly  rewritten and routed out an outgoing TCP/IP channel.

In newer configurations, a similar effect is obtained via the special rewrite rule: . $U%$H$,$H@TCP-DAEMON where the special   sequence  causes a lookup of the entire unmatched domain (the  ) in the   file (the  ) listing current Top Level Domains.

IP domain literals follow a similar hierarchical matching pattern, though with right-to-left (rather than left-to-right) matching. For instance, the pattern &#x5b;1.2.3.4&#x5d; matches only and exactly the IP literal &#x5b;1.2.3.4&#x5d;, while &#x5b;1.2.3.&#x5d; matches anything in the 1.2.3.0 subnet.

In addition to the more common sorts of host or subdomain rewrite rule patterns discussed above, rewrite rules may also make use of several  special patterns, summarized in  Summary of special patterns for rewrite rules, and discussed in the  following subsections.

In addition to these special patterns, the MTA also has the concept of "tags" which may appear in rewrite rule patterns. These tags are used in situations where an address may be rewritten several times  and, based upon previous rewritings, distinctions must be made in  subsequent rewritings by controlling which rewrite rules match the  address; see Tagged rewrite rule sets.

See also:
 * Initial match-all rule
 * A rule to match percent hacks
 * A rule to match bang-style addresses
 * A rule to match any domain literal
 * Rules to match domains containing exact numbers of components
 * A rule to match any address
 * TLD comparison rewrites
 * Tagged rewrite rule sets
 * Rewrite rules