FreeBSD Manual Pages
REGEXP_TABLE(5) File Formats Manual REGEXP_TABLE(5) NAME regexp_table - format of Postfix regular expression tables SYNOPSIS postmap -q "string" regexp:$config_directory/filename postmap -q - regexp:$config_directory/filename <inputfile DESCRIPTION The Postfix mail system uses optional tables for address rewriting, mail routing, or access control. These tables are usually in dbm or db format. Alternatively, lookup tables can be specified in POSIX regular expres- sion form. In this case, each input is compared against a list of pat- terns. When a match is found, the corresponding result is returned and the search is terminated. To find out what types of lookup tables your Postfix system supports use the "postconf -m" command. To test lookup tables, use the "postmap -q" command as described in the SYNOPSIS above. Use "postmap -hmq - <file" for header_checks(5) pat- terns, and "postmap -bmq - <file" for body_checks(5) (Postfix 2.6 and later). COMPATIBILITY With Postfix version 2.2 and earlier specify "postmap -fq" to query a table that contains case sensitive patterns. Patterns are case insensi- tive by default. TABLE FORMAT The general form of a Postfix regular expression table is: /pattern/flags result When pattern matches the input string, use the corresponding re- sult value. !/pattern/flags result When pattern does not match the input string, use the corre- sponding result value. if /pattern/flags endif If the input string matches /pattern/, then match that input string against the patterns between if and endif. The if..endif can nest. Note: do not prepend whitespace to patterns inside if..endif. This feature is available in Postfix 2.1 and later. if !/pattern/flags endif If the input string does not match /pattern/, then match that input string against the patterns between if and endif. The if..endif can nest. Note: do not prepend whitespace to patterns inside if..endif. This feature is available in Postfix 2.1 and later. blank lines and comments Empty lines and whitespace-only lines are ignored, as are lines whose first non-whitespace character is a `#'. multi-line text A logical line starts with non-whitespace text. A line that starts with whitespace continues a logical line. Each pattern is a POSIX regular expression enclosed by a pair of delim- iters. The regular expression syntax is documented in re_format(7) with 4.4BSD, in regex(5) with Solaris, and in regex(7) with Linux. Other systems may use other document names. The expression delimiter can be any non-alphanumerical character, ex- cept whitespace or characters that have special meaning (traditionally the forward slash is used). The regular expression can contain white- space. By default, matching is case-insensitive, and newlines are not treated as special characters. The behavior is controlled by flags, which are toggled by appending one or more of the following characters after the pattern: i (default: on) Toggles the case sensitivity flag. By default, matching is case insensitive. m (default: off) Toggle the multi-line mode flag. When this flag is on, the ^ and $ metacharacters match immediately after and immediately before a newline character, respectively, in addition to matching at the start and end of the input string. x (default: on) Toggles the extended expression syntax flag. By default, support for extended expression syntax is enabled. TABLE SEARCH ORDER Patterns are applied in the order as specified in the table, until a pattern is found that matches the input string. Each pattern is applied to the entire input string. Depending on the application, that string is an entire client hostname, an entire client IP address, or an entire mail address. Thus, no parent domain or par- ent network search is done, and user@domain mail addresses are not bro- ken up into their user and domain constituent parts, nor is user+foo broken up into user and foo. TEXT SUBSTITUTION Substitution of substrings (text that matches patterns inside "()") from the matched expression into the result string is requested with $1, $2, etc.; specify $$ to produce a $ character as output. The macros in the result string may need to be written as ${n} or $(n) if they aren't followed by whitespace. Note: since negated patterns (those preceded by !) return a result when the expression does not match, substitutions are not available for negated patterns. INLINE SPECIFICATION The contents of a table may be specified in the table name (Postfix 3.7 and later). The basic syntax is: main.cf: parameter = .. regexp:{ { rule-1 }, { rule-2 } .. } .. master.cf: .. -o { parameter = .. regexp:{ { rule-1 }, { rule-2 } .. } .. } .. Postfix recursively expands any $parametername instances in the above parameter value, ignores whitespace after '{' and before '}', and writes each rule as one text line to an in-memory file: in-memory file: rule-1 rule-2 .. Postfix parses the result as if it is a file in /usr/local/etc/postfix. INLINE SPECIFICATION CAVEATS • Avoid using $parametername inside an inlined regexp: pattern. The pattern would have unexpected matches when there are metacharacters such as '.' in the $parametername expansion. To prevent unexpected matches, use a pcre: table, and specify \Q$parametername\E. • When an inlined rule must contain $, specify $$ to keep Postfix from trying to do $name expansion as it evaluates a parameter value. To check an inline configuration, use the "postconf -x" option as shown below: • When a main.cf "parametername = value" setting contains an inline regexp: table, use the command "postconf -x pa- rametername". Verify that there are no "undefined parame- ter" warnings, and that the output has the syntax that one would use in a non-inlined Postfix regexp: file. • When a master.cf "-o { parametername = value }" override contains an inline regexp: table, use the command "post- conf -Px '*/*/parametername' ". Verify that there are no "undefined parameter" warnings, and that the output has the syntax that one would use in a non-inlined Postfix regexp: file. EXAMPLE SMTPD ACCESS MAP # Disallow sender-specified routing. This is a must if you relay mail # for other domains. /[%!@].*[%!@]/ 550 Sender-specified routing rejected # Postmaster is OK, that way they can talk to us about how to fix # their problem. /^postmaster@/ OK # Protect your outgoing majordomo exploders if !/^owner-/ /^(.*)-outgoing@(.*)$/ 550 Use ${1}@${2} instead endif EXAMPLE HEADER FILTER MAP # These were once common in junk mail. /^Subject: make money fast/ REJECT /^To: friend@public\.com/ REJECT EXAMPLE BODY FILTER MAP # First skip over base 64 encoded text to save CPU cycles. ~^[[:alnum:]+/]{60,}$~ OK # Put your own body patterns here. SEE ALSO postmap(1), Postfix lookup table manager pcre_table(5), format of PCRE tables cidr_table(5), format of CIDR tables README FILES Use "postconf readme_directory" or "postconf html_directory" to locate this information. DATABASE_README, Postfix lookup table overview AUTHOR(S) The regexp table lookup code was originally written by: LaMont Jones lamont@hp.com That code was based on the PCRE dictionary contributed by: Andrew McNamara andrewm@connect.com.au connect.com.au Pty. Ltd. Level 3, 213 Miller St North Sydney, NSW, Australia Adopted and adapted by: Wietse Venema IBM T.J. Watson Research P.O. Box 704 Yorktown Heights, NY 10598, USA Wietse Venema Google, Inc. 111 8th Avenue New York, NY 10011, USA REGEXP_TABLE(5)
NAME | SYNOPSIS | DESCRIPTION | COMPATIBILITY | TABLE FORMAT | TABLE SEARCH ORDER | TEXT SUBSTITUTION | INLINE SPECIFICATION | INLINE SPECIFICATION CAVEATS | EXAMPLE SMTPD ACCESS MAP | EXAMPLE HEADER FILTER MAP | EXAMPLE BODY FILTER MAP | SEE ALSO | README FILES | AUTHOR(S)
Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=regexp_table&sektion=5&manpath=FreeBSD+Ports+14.3.quarterly>