14.4. Rewriting Patterns

The source pattern in a rewriting rule can be in one of the forms in the following list. It is not enclosed in quotes, and there is no special processing of any characters; it is not expanded. If it is a regular expression, backslash characters do not need to be doubled.

• An address containing a local part and a domain, either of which may start with an asterisk, implying independent wildcard matching, for example:

  *@orchestra-land.example

  
  

  If the domain is specified as a single @ character, it matches the primary hostname. After matching, the numerical variables refer to the character strings matched by asterisks, with $0 referring to the entire address, $1 referring to the first asterisk, and $2 referring to the second asterisk, if present. For example, if the pattern:

  *queen@*.example

  
  

  is matched against the address hearts-queen@wonderland.example, the three variables would be set as follows:

  $0 = hearts-queen@wonderland.example
  $1 = hearts-
  $2 = wonderland

  
  

  Note that if the local part does not start with an asterisk, but the domain does, it is $1 that contains the wild part of the domain.

• A local part, possibly starting with an asterisk, and a lookup item (as in a domain list), for example:

  root@lsearch;/etc/special/domains

  
  

  If there is an asterisk in the local part, the value of the wild part is placed in the first numerical variable. If the lookup is a partial one, the wild part of the domain is placed in the next numerical variable, and the fixed part of the domain is placed in the succeeding variable. Thus, for example, if the address foo@bar.baz.example is processed by a rewriting rule using the pattern:

  *@partial-dbm;/some/dbm/file

  
  

  and the key in the file that matches the domain is *.baz.example, the three variables would be set as follows:

  $1 = foo
  $2 = bar
  $3 = baz.example

  
  

  If the address foo@baz.example is looked up, this matches the same wildcard file entry, and in this case $2 is set to the empty string but $3 is still set to baz.example. If a nonwild key is matched in a partial lookup, $2 is set to the empty string and $3 is set to the whole domain again. For nonpartial lookups, no numerical variables are set.

• A local part, possibly starting with an asterisk and a regular expression (as in a domain list), for example:

  *.queen@^(wonderland|lookingglass)\.example$

  
  

  If there is an asterisk in the local part, the value of the wild part is placed in the first numerical variable. Any substrings captured by the regular expression are placed in numerical variables starting at $1 if there is no asterisk in the local part, or at $2 if there is.

• A lookup without a local part, for example:

  partial-dbm;/rewrite/database

  
  

  This works similarly for an address list configuration item; the domain is first looked up, possibly partially, and if that fails, the whole address is looked up (not partially). When a partial lookup succeeds, the numerical variable $1 contains the wild part of the domain, and $2 contains the fixed part. The @@ form of address list lookup can also be used.

• A single regular expression. This is matched against the entire address, with the domain part lowercased. After matching, the numerical variables refer to the bracketed capturing subexpressions, with $0 referring to the entire address. For example, if the following pattern:

  ^(red|white)\.king@(wonderland|lookingglass)\.example$

  
  

  is matched against the address red.king@lookingglass.example, then the variables would be set as follows:

  $0 = red.king@lookingglass.example
  $1 = red
  $2 = lookingglass

  
  

  Note that, because the pattern part of a rewriting rule is terminated by whitespace, no literal whitespace may be present in the regular expression.