sandbox

package: policycoreutils-sandbox

title: sandbox(5)

text:
# sandbox(5)

## NAME
sandbox.conf - user config file for the SELinux sandbox

## DESCRIPTION
When running sandbox with the -C argument, it will be confined using control groups and a system administrator can specify how the sandbox is confined.

Everything after "#" is ignored, as are empty lines. All arguments should be separated by and equals sign ("=").

These keywords are allowed.

NAME

The name of the sandbox control group. Default is "sandbox".

CPUAFFINITY

Which cpus to assign sandbox to. The default is ALL, but users can specify a comma-separated list with dashes ("-") to represent ranges. Ex: 0-2,5

MEMUSAGE

How much memory to allow sandbox to use. The default is 80%. Users can specify either a percentage or a value in the form of a number followed by one of the suffixes K, M, G to denote kilobytes, megabytes or gigabytes respectively. Ex: 50% or 100M

CPUUSAGE

Percentage of cpu sandbox should be allowed to use. The default is 80%. Specify a value followed by a percent sign ("%"). Ex: 50%

## SEE ALSO
sandbox(8)

## AUTHOR
This manual page was written by Thomas Liu <tliu@fedoraproject.org>


policyd-weight.conf

package: policyd-weight

title: policyd-weight.conf(5)

text:
# policyd-weight.conf(5)

## NAME
policyd-weight.conf - policyd-weight configuration parameters

## STATUS
Beta, Documentation incomplete

## DESCRIPTION

policyd-weight uses a perl(1) style configuration file which it reads on startup. The cache re-reads the configuration after $MAINTENANCE_LEVEL (default: 5) queries. If -f is not specified, it searches for configuration files on following locations:

/etc/policyd-weight.conf

/usr/local/etc/policyd-weight.conf

./policyd-weight.conf

## CACHE SETTINGS

$CACHESIZE (default: 2000)

Set the minimum size of the SPAM cache.

$CACHEMAXSIZE (default: 4000)

Set the maximum size of the SPAM cache.

$CACHEREJECTMSG

(default: 550 temporarily blocked because of previous errors)" Set the SMTP status code and a explanatory message for rejected mails due to cached results

$NTTL (default: 1)

The client is penalized for that many retries.

$NTIME (default: 30)

The $NTTL counter will only be decremented if the client waits at least $NTIME seconds.

$POSCACHESIZE (default: 1000)

Set the minimum size of the HAM cache.

$POSCACHEMAXSIZE (default: 2000)

Set the maximum size of the HAM cache.

$PTTL (default: 60)

After that many queries the HAM entry must succeed one run through the RBL checks again.

$PTIME (default: 3h)

after $PTIME in HAM Cache the client must pass one time the RBL checks again. Values must be nonfractal. Accepted time-units: s(econds), m(inutes), h(ours), d(ays)

$TEMP_PTIME (default: 1d)

The client must pass this time the RBL checks in order to be listed as hard-HAM. After this time the client will pass immediately for PTTL within PTIME. Values must be non-fractal. Accepted time-units: s(econds), m(inutes), h(ours), d(ays)

## DEBUG SETTINGS

$DEBUG (default: 0)

Turn debugging on (1) or off (0)

## DNS SETTINGS

$DNS_RETRIES (default: 2)

How many times a single DNS query may be repeated

$DNS_RETRY_IVAL (default: 2)

Retry a query without response after that many seconds

$MAXDNSERR (default: 3)

If that many queries fail, the mail is accepted with $MAXDNSERRMSG.

In total DNS queries this means: $MAXDNSERR * $DNS_RETRIES

## MISC SETTINGS

$MAINTENANCE_LEVEL (default: 5)

After that many policy requests the cache (and in daemon mode childs) checks for configuration file changes

$MAXIDLECACHE (default: 60)

After that many seconds of being idle the cache checks for configuration file changes.

$PIDFILE (default: /var/run/policyd-weight.pid)

Path and filename to store the master pid (daemon mode)

$LOCKPATH (default: /tmp/.policyd-weight/)

Directory where policyd-weight stores sockets and lock-files/directories. Its argument must contain a trailing slash.

$SPATH (default: $LOCKPATH.'/polw.sock')

Path and filename which the cache has to use for communication.

$TCP_PORT (default: 12525)

TCP port on which the policy server listens (daemon mode)

$BIND_ADDRESS (default: '127.0.0.1')

IP Address on which policyd-weight binds. Currently either only one or all IPs are supported. Specify 'all' if you want to listen on all IPs.

$SOMAXCONN (default: 1024)

Maximum connections which policyd-weight accepts. This is set high enough to cover most scenarios.

$USER (default: polw)

Set the user under which policyd-weight runs

$GROUP (default: $USER)

Set the group under which policyd-weight runs

## OUTPUT AND LOG SETTINGS

$ADD_X_HEADER (default: 1)

Insert a X-policyd-weight: header with evaluation messages.

1 = on, 0 = off

$LOG_BAD_RBL_ONLY (default: 1)

Insert only RBL results in logging strings if the RBL score changes the overall score. Thus RBLs with a GOOD SCORE of 0 don't appear in logging strings if the RBL returned no BAD hit.

1 = on, 0 = off

$MAXDNSBLMSG (default: 550 Your MTA is listed in too many DNSBLs)

The message sent to the client if it was reject due to $MAXDNSBLHITS and/or $MAXDNSBLSCORE.

$REJECTMSG (default: 550 Mail appeared to be SPAM or forged. Ask your Mail/DNS-Adminisrator to correct HELO and DNS MX settings or to get removed from DNSBLs)

Set the SMTP status code for rejected mails and a message why the action was taken

## RESOURCE AND OPTIMIZATIONS

$CHILDIDLE (default: 120)

How many seconds a child may be idle before it dies (daemon mode)

$MAX_PROC (default: 50)

Process limit on how many processes policyd-weight will spawn (daemon mode)

$MIN_PROC (default: 2)

Minimum childs which are kept alive in idle times (daemon mode)

$PUDP (default: 0)

Set persistent UDP connections used for DNS queries on (1) or off (0).

## SCORE SETTINGS

Positive values indicate a bad (SPAM) score, negative values indicate a good (HAM) score.

@bogus_mx_score (2.1, 0)

If the sender domain has neither MX nor A records or these records resolve to a bogus IP-Address (for instance private networks) then this check asigns the full score of bogus_mx_score. If there is no MX but an A record of the sender domain then it receives a penalty only if DNSBL-listed. Log Entries:

BOGUS_MX

The sender A and MX records are bogus or empty.

BAD_MX

The sender domain has an empty or bogus MX record and the client is DNSBL listed.

Related RFCs:

[1918] Address Allocation for Private Internets

[2821] Simple Mail Transfer Protocol (Sect 3.6 and Sect 5)

@client_ip_eq_helo_score (1.5, -1.25)

Define scores for the match of the reverse record (hostname) against the HELO argument. Reverse lookups are done, if the forward lookups failed and are not trusted. Log Entries:

REV_IP_EQ_HELO

The Client's PTR matched the HELO argument.

REV_IP_EQ_HELO_DOMAIN

Domain portions of Client PTR and HELO argument matched.

RESOLVED_IP_IS_NOT_HELO

Client PTRs found but did not match HELO argument.

@helo_score (1.5, -2)

Define scores for the match of the Client IP and its /24 subnet against the A records of HELO or MAIL FROM domain/host. It also holds the bad score for MX verifications. Log Entries:

CL_IP_EQ_HELO_NUMERIC

Client IP matches the [IPv4] HELO.

CL_IP_EQ_FROM_IP

Client IP matches the A record of the MAIL FROM sender domain/host.

CL_IP_EQ_HELO_IP

Client IP matches the A record of the HELO argument.

CL_IP_NE_HELO

The IP and the /24 subnet did not match A/MX records of HELO and MAIL FROM arguments and their subdomains.

@helo_from_mx_eq_ip_score (1.5, -3.1)

Define scores for the match of Client IP against MX records. Positive (SPAM) values are used in case the MAIL FROM matches not the HELO argument AND the client seems to be dynamic AND the client is no MX for HELO and MAIL FROM arguments. The total DNSBL score is added to its bad score. Log Entries:

CL_IP_EQ_FROM_MX

Client IP matches the MAIL FROM domain/host MX record

CL_IP_EQ_HELO_MX

Client IP matches the HELO domain/host MX record

CLIENT_NOT_MX/A_FROM_DOMAIN

Client is not a verified HELO and doesn't match A/MX records of MAIL FROM argument

CLIENT/24_NOT_MX/A_FROM_DOMAIN

Client's subnet does not match A/MX records of the MAIL FROM argument

$dnsbl_checks_only (default: 0)

Disable HELO/RHSBL verifications and the like. Do only RBL checks.

1 = on, 0 = off

@dnsbl_score (default: see below)

A list of RBLs to be checked. If you want that a host is not being evaluated any further if it is listed on several lists or a very trustworthy list you can control a immediate REJECT with $MAXDNSBLHITS and/or $MAXDNSBLSCORE. A list of RBLs must be build as follows: @dnsbl_score = (

RBLHOST1, HIT SCORE, MISS SCORE, LOG NAME,

RBLHOST2, HIT SCORE, MISS SCORE, LOG NAME,

...

);

The default is:

@dnsbl_score = (

"pbl.spamhaus.org", 3.25, 0, "DYN_PBL_SPAMHAUS",

"dnsbl.njabl.org", 4.25, -1.5, "BL_NJABL",

"bl.spamcop.net", 1.75, -1.5, "SPAMCOP",

"sbl-xbl.spamhaus.org", 4.35, -1.5, "SBL_XBL_SPAMHAUS",

"list.dsbl.org", 4.35, 0, "DSBL_ORG",

"ix.dnsbl.manitu.net", 4.35, 0, "IX_MANITU",

"relays.ordb.org", 3.25, 0, "ORDB_ORG"

);

@rhsbl_score (default: see below)

Define a list of RHSBL host which are queried for the sender domain. Results get additionaly scores of 0.5 * DNSBL results and @rhsbl_penalty_score. A list of RHSBL hosts to be queried must be build as follows: @rhsbl_score = (

RHSBLHOST1, HIT SCORE, MISS SCORE, LOG NAME,

RHSBLHOST2, HIT SCORE, MISS SCORE, LOG NAME,

...

);

The default is:

@rhsbl_score = (

"rhsbl.ahbl.org", 1.8, 0, "AHBL",

"dsn.rfc-ignorant.org", 3.2, 0, "DSN_RFCI",

"postmaster.rfc-ignorant.org", 1 , 0, "PM_RFCI",

"abuse.rfc-ignorant.org", 1, 0, "ABUSE_RFCI"

);

@rhsbl_penalty_score (3.1, 0)

This score will be added to each RHSBL hit if following criterias are met:

Sender has a random local-part (i.e. yztrzgb@example.tld)

or MX records of sender domain are bogus

or FROM matches not HELO

or HELO is untrusted (Forward record matched, reverse record

did not match)

$MAXDNSBLHITS (default: 2)

If the client is listed in more than $MAXDNSBLHITS RBLs it will be rejected immediately with $MAXDNSBLMSG and without further evaluation. Results are cached by default.

$MAXDNSBLSCORE (default: 8)

If the BAD SCOREs of @dnsbl_score listed RBLs reach a level greater than $MAXDNSBLSCORE the client will be rejected immediately with $MAXDNSBLMSG and without further evaluation. Results are cached by default.

$REJECTLEVEL (default: 1)

Score results equal or greater than this level will be rejected with $REJECTMSG

## SEE ALSO

```
policyd-weight(8), Policyd-weight daemon
perl(1), Practical Extraction and Report Language
perlsyn(1), Perl syntax
access(5), Postfix SMTP access control table
```

## LICENSE

```
GNU General Public License
```

## AUTHOR

```
Robert Felber <r.felber@ek-muc.de>
Autohaus Erich Kuttendreier
81827 Munich, Germany
```

branch: sisyphus


polybar

package: polybar

title: polybar(5)

summary: configuration file for polybar(1)

text:
# polybar(5)

## NAME
polybar - configuration file for polybar(1)

## DESCRIPTION
The polybar configuration file defines the behavior and look of polybar. It uses a variant of the INI <https://en.wikipedia.org/wiki/INI_file> file format. The exact syntax is described below but first a small snippet to get familiar with the syntax:

```
[section_name]
; A comment
# Another comment
background = #ff992a
width = 90%
monitor = HDMI-0
screenchange-reload = false
; Use double quotes if you want to keep the surrounding space.
text = " Some text "
```

When started polybar will search for the config file in one of several places in the following order:

- If the -c or --config command line argument is specified, it will use the path given there.

- $XDG_CONFIG_HOME/polybar/config

- $XDG_CONFIG_HOME/polybar/config.ini

- $HOME/.config/polybar/config

- $HOME/.config/polybar/config.ini

- $XDG_CONFIG_DIRS/polybar/config.ini

- /etc/xdg/polybar/config.ini (only if XDG_CONFIG_DIRS is not set)

- /etc/polybar/config.ini

## SYNTAX
The entire config is line-based so everything is constrained to a single line. This means there are no multiline values or other multiline constructs (except for sections). Each line has one of four types:

- Empty

- Comment

- Section Header

- Key

Spaces at the beginning and end of each line will be ignored.

Note:

In this context "spaces" include the regular space character as well as the tab character and any other character for which isspace(3) returns true (e.g. \r).

Any line that doesn't fit into one of these four types is a syntax error.

Note:

It is recommended that section header names and key names only use alphanumeric characters as well as dashes (-), underscores (_) and forward slashes (/). In practice all characters are allowed except for spaces and any of these: "'=;#[](){}:.$\%

### Section Headers
Sections are used to group config options together. For example each module is defined in its own section.

A section is defined by placing the name of the section in square brackets ([ and ]). For example:

```
[module/wm]
```

This declares a section with the name module/wm and all keys defined after this line will belong to that section until a new section is declared.

Warning:

The first non-empty and non-comment line in the main config file must be a section header. It cannot be a key because that key would not belong to any section.

Note:

The following section names are reserved and cannot be used inside the config: self, root, and BAR.

### Keys
Keys are defined by assigning a value to a name like this:

```
name = value
```

This assigns value to the key name in whatever section this line is in. Key names need to be unique per section. If the value is enclosed by double-quotes ("), the quotes will be ignored. So the following still assigns value to name:

```
name = "value"
```

Spaces around the equal sign are ignored, the following are all equivalent:

```
name=value
name = value
name =      value
```

Because spaces at the beginning and end of the line are also ignored, if you want your value to begin and/or end with a space, the value needs to be enclosed in double-quotes:

```
name = " value "
```

Here the value of the name key has a leading and trailing whitespace.

To treat characters with special meaning as literal characters, you need to prepend them with the backslash (\) escape character:

```
name = "value\\value\\value"
```

Value of this key name results in value\value\value.

Note:

The only character with a special meaning right now is the backslash character (\), which serves as the escape character. More will be added in the future.

### Empty Lines & Comments
Empty lines and comment lines are ignored when reading the config file, they do not affect polybar's behavior. Comment lines start with either the ; or the # character.

Note:

Inline comments are not supported. For example the following line does not end with a comment, the value of name is actually set to value ; comment:

```
name = value ; comment
```

## AUTHORS

```
Polybar was created by Michael Carlberg and is currently maintained by Patrick Ziegler.
Contributors can be listed on GitHub.
```

## SEE ALSO
polybar(1), polybar-msg(1)

## Copyright
2016-2026, Michael Carlberg & contributors


access

package: postfix

title: access(5)

text:
# access(5)

## NAME
access - Postfix SMTP server access table

## SYNOPSIS

```
postmap /etc/postfix/access
postmap -q "string" /etc/postfix/access
postmap -q - /etc/postfix/access <inputfile
```

## DESCRIPTION

This document describes access control on remote SMTP client information: host names, network addresses, and envelope sender or recipient addresses; it is implemented by the Postfix SMTP server. See header_checks(5) or body_checks(5) for access control on the content of email messages.

Normally, the access(5) table is specified as a text file that serves as input to the postmap(1) command. The result, an indexed file in dbm or db format, is used for fast searching by the mail system. Execute the command "postmap /etc/postfix/access" to rebuild an indexed file after changing the corresponding text file.

When the table is provided via other means such as NIS, LDAP or SQL, the same lookups are done as for ordinary indexed files.

Alternatively, the table can be provided as a regular-expression map where patterns are given as regular expressions, or lookups can be directed to a TCP-based server. In those cases, the lookups are done in a slightly different way as described below under "REGULAR EXPRESSION TABLES" or "TCP-BASED TABLES".

## CASE FOLDING

```

```

The search string is folded to lowercase before database lookup. As of Postfix 2.3, the search string is not case folded with database types such as regexp: or pcre: whose lookup fields can match both upper and lower case.

## TABLE FORMAT

```

```

The input format for the postmap(1) command is as follows:

pattern action

When pattern matches a mail address, domain or host address, perform the corresponding action.

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.

## EMAIL ADDRESS PATTERNS

```

```

With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, patterns are tried in the order as listed below:

user@domain

Matches the specified mail address.

domain.tld

Matches domain.tld as the domain part of an email address. The pattern domain.tld also matches subdomains, but only when the string smtpd_access_maps is listed in the Postfix parent_domain_matches_subdomains configuration setting.

.domain.tld

Matches subdomains of domain.tld, but only when the string smtpd_access_maps is not listed in the Postfix parent_domain_matches_subdomains configuration setting.

user@

Matches all mail addresses with the specified user part.

Note: lookup of the null sender address is not possible with some types of lookup table. By default, Postfix uses <> as the lookup key for such addresses. The value is specified with the smtpd_null_access_lookup_key parameter in the Postfix main.cf file.

## EMAIL ADDRESS EXTENSION

```

```

When a mail address localpart contains the optional recipient delimiter (e.g., user+foo@domain), the lookup order becomes: user+foo@domain, user@domain, domain, user+foo@, and user@.

## HOST NAME/ADDRESS PATTERNS

```

```

With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, the following lookup patterns are examined in the order as listed:

domain.tld

Matches domain.tld. The pattern domain.tld also matches subdomains, but only when the string smtpd_access_maps is listed in the Postfix parent_domain_matches_subdomains configuration setting.

.domain.tld

Matches subdomains of domain.tld, but only when the string smtpd_access_maps is not listed in the Postfix parent_domain_matches_subdomains configuration setting.

net.work.addr.ess

net.work.addr

net.work

net

Matches a remote IPv4 host address or network address range. Specify one to four decimal octets separated by ".". Do not specify "[]" , "/", leading zeros, or hexadecimal forms. Network ranges are matched by repeatedly truncating the last ".octet" from a remote IPv4 host address string, until a match is found in the access table, or until further truncation is not possible.

NOTE: use the cidr lookup table type to specify network/netmask patterns. See cidr_table(5) for details.

net:work:addr:ess

net:work:addr

net:work

net

Matches a remote IPv6 host address or network address range. Specify three to eight hexadecimal octet pairs separated by ":", using the compressed form "::" for a sequence of zero-valued octet pairs. Do not specify "[]", "/", leading zeros, or non-compressed forms. A network range is matched by repeatedly truncating the last ":octetpair" from the compressed-form remote IPv6 host address string, until a match is found in the access table, or until further truncation is not possible.

NOTE: use the cidr lookup table type to specify network/netmask patterns. See cidr_table(5) for details.

IPv6 support is available in Postfix 2.2 and later.

## ACCEPT ACTIONS

```

```

OK

Accept the address etc. that matches the pattern.

all-numerical

An all-numerical result is treated as OK. This format is generated by address-based relay authorization schemes such as pop-before-smtp.

For other accept actions, see "OTHER ACTIONS" below.

## REJECT ACTIONS

```

```

Postfix version 2.3 and later support enhanced status codes as defined in RFC 3463. When no code is specified at the beginning of the text below, Postfix inserts a default enhanced status code of "5.7.1" in the case of reject actions, and "4.7.1" in the case of defer actions. See "ENHANCED STATUS CODES" below.

4NN text

5NN text

Reject the address etc. that matches the pattern, and respond with the numerical three-digit code and text. 4NN means "try again later", while 5NN means "do not try again". The following responses have special meaning for the Postfix SMTP server:

421 text (Postfix 2.3 and later)

521 text (Postfix 2.6 and later)

After responding with the numerical three-digit code and text, disconnect immediately from the SMTP client. This frees up SMTP server resources so that they can be made available to another SMTP client.

Note: The "521" response should be used only with botnets and other malware where interoperability is of no concern. The "send 521 and disconnect" behavior is NOT defined in the SMTP standard.

REJECT optional text...

Reject the address etc. that matches the pattern. Reply with "$access_map_reject_code optional text..." when the optional text is specified, otherwise reply with a generic error response message.

DEFER optional text...

Reject the address etc. that matches the pattern. Reply with "$access_map_defer_code optional text..." when the optional text is specified, otherwise reply with a generic error response message. This feature is available in Postfix 2.6 and later.

DEFER_IF_REJECT optional text...

Defer the request if some later restriction would result in a REJECT action. Reply with "$access_map_defer_code 4.7.1 optional text..." when the optional text is specified, otherwise reply with a generic error response message. Prior to Postfix 2.6, the SMTP reply code is 450.

This feature is available in Postfix 2.1 and later.

DEFER_IF_PERMIT optional text...

Defer the request if some later restriction would result in an explicit or implicit PERMIT action. Reply with "$access_map_defer_code 4.7.1 optional text..." when the optional text is specified, otherwise reply with a generic error response message. Prior to Postfix 2.6, the SMTP reply code is 450.

This feature is available in Postfix 2.1 and later.

For other reject actions, see "OTHER ACTIONS" below.

## OTHER ACTIONS

```

```

restriction...

Apply the named UCE restriction(s) (permit, reject, reject_unauth_destination, and so on).

BCC user@domain

Send one copy of the message to the specified recipient. If multiple BCC actions are specified within the same SMTP MAIL transaction, with Postfix 3.0 only the last action will be used.

This feature is available in Postfix 3.0 and later.

DISCARD optional text...

Claim successful delivery and silently discard the message. Log the optional text if specified, otherwise log a generic message. Note: this action currently affects all recipients of the message. To discard only one recipient without discarding the entire message, use the transport(5) table to direct mail to the discard(8) service.

This feature is available in Postfix 2.0 and later.

DUNNO

Pretend that the lookup key was not found. This prevents Postfix from trying substrings of the lookup key (such as a subdomain name, or a network address subnetwork). This feature is available in Postfix 2.0 and later.

FILTER transport:destination

After the message is queued, send the entire message through the specified external content filter. The transport name specifies the first field of a mail delivery agent definition in master.cf; the syntax of the next-hop destination is described in the manual page of the corresponding delivery agent. More information about external content filters is in the Postfix FILTER_README file. Note 1: do not use $number regular expression substitutions for transport or destination unless you know that the information has a trusted origin.

Note 2: this action overrides the main.cf content_filter setting, and affects all recipients of the message. In the case that multiple FILTER actions fire, only the last one is executed.

Note 3: the purpose of the FILTER command is to override message routing. To override the recipient's transport but not the next-hop destination, specify an empty filter destination (Postfix 2.7 and later), or specify a transport:destination that delivers through a different Postfix instance (Postfix 2.6 and earlier). Other options are using the recipient-dependent transport_maps or the sender-dependent sender_dependent_default_transport_maps features.

This feature is available in Postfix 2.0 and later.

HOLD optional text...

Place the message on the hold queue, where it will sit until someone either deletes it or releases it for delivery. Log the optional text if specified, otherwise log a generic message. Mail that is placed on hold can be examined with the postcat(1) command, and can be destroyed or released with the postsuper(1) command.

Note: use "postsuper -r" to release mail that was kept on hold for a significant fraction of $maximal_queue_lifetime or $bounce_queue_lifetime, or longer. Use "postsuper -H" only for mail that will not expire within a few delivery attempts.

Note: this action currently affects all recipients of the message.

This feature is available in Postfix 2.0 and later.

PREPEND headername: headervalue

Prepend the specified message header to the message. When more than one PREPEND action executes, the first prepended header appears before the second etc. prepended header. Note: this action must execute before the message content is received; it cannot execute in the context of smtpd_end_of_data_restrictions.

This feature is available in Postfix 2.1 and later.

REDIRECT user@domain

After the message is queued, send the message to the specified address instead of the intended recipient(s). When multiple REDIRECT actions fire, only the last one takes effect. Note: this action overrides the FILTER action, and currently overrides all recipients of the message.

This feature is available in Postfix 2.1 and later.

INFO optional text...

Log an informational record with the optional text, together with client information and if available, with helo, sender, recipient and protocol information. This feature is available in Postfix 3.0 and later.

WARN optional text...

Log a warning with the optional text, together with client information and if available, with helo, sender, recipient and protocol information. This feature is available in Postfix 2.1 and later.

## ENHANCED STATUS CODES

```

```

Postfix version 2.3 and later support enhanced status codes as defined in RFC 3463. When an enhanced status code is specified in an access table, it is subject to modification. The following transformations are needed when the same access table is used for client, helo, sender, or recipient access restrictions; they happen regardless of whether Postfix replies to a MAIL FROM, RCPT TO or other SMTP command.

- When a sender address matches a REJECT action, the Postfix SMTP server will transform a recipient DSN status (e.g., 4.1.1-4.1.6) into the corresponding sender DSN status, and vice versa.

- When non-address information matches a REJECT action (such as the HELO command argument or the client hostname/address), the Postfix SMTP server will transform a sender or recipient DSN status into a generic non-address DSN status (e.g., 4.0.0).

## REGULAR EXPRESSION TABLES

```

```

This section describes how the table lookups change when the table is given in the form of regular expressions. For a description of regular expression lookup table syntax, see regexp_table(5) or pcre_table(5).

Each pattern is a regular expression that is applied to the entire string being looked up. 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 parent network search is done, user@domain mail addresses are not broken up into their user@ and domain constituent parts, nor is user+foo broken up into user and foo.

Patterns are applied in the order as specified in the table, until a pattern is found that matches the search string.

Actions are the same as with indexed file lookups, with the additional feature that parenthesized substrings from the pattern can be interpolated as $1, $2 and so on.

## TCP-BASED TABLES

```

```

This section describes how the table lookups change when lookups are directed to a TCP-based server. For a description of the TCP client/server lookup protocol, see tcp_table(5). This feature is not available up to and including Postfix version 2.4.

Each lookup operation uses the entire query string once. 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 parent network search is done, user@domain mail addresses are not broken up into their user@ and domain constituent parts, nor is user+foo broken up into user and foo.

Actions are the same as with indexed file lookups.

## EXAMPLE

```

```

The following example uses an indexed file, so that the order of table entries does not matter. The example permits access by the client at address 1.2.3.4 but rejects all other clients in 1.2.3.0/24. Instead of hash lookup tables, some systems use dbm. Use the command "postconf -m" to find out what lookup tables Postfix supports on your system.

```
/etc/postfix/main.cf:

    smtpd_client_restrictions =

        check_client_access hash:/etc/postfix/access
/etc/postfix/access:

    1.2.3   REJECT

    1.2.3.4 OK
```

Execute the command "postmap /etc/postfix/access" after editing the file.

## BUGS

The table format does not understand quoting conventions.

## SEE ALSO

```
postmap(1), Postfix lookup table manager
smtpd(8), SMTP server
postconf(5), configuration parameters
transport(5), transport:nexthop syntax
```

## README FILES

```

```

Use "postconf readme_directory" or "postconf html_directory" to locate this information.

```
SMTPD_ACCESS_README, built-in SMTP server access control
DATABASE_README, Postfix lookup table overview
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## AUTHOR(S)

```
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
```


aliases

title: aliases(5)

text:
# aliases(5)

## NAME
aliases - Postfix local alias database format

## SYNOPSIS

```

```

newaliases

## DESCRIPTION

The aliases(5) table provides a system-wide mechanism to redirect mail for local recipients. The redirections are processed by the Postfix local(8) delivery agent.

Normally, the aliases(5) table is specified as a text file that serves as input to the postalias(1) command. The result, an indexed file in dbm or db format, is used for fast lookup by the mail system. Execute the command newaliases in order to rebuild the indexed file after changing the Postfix alias database.

When the table is provided via other means such as NIS, LDAP or SQL, the same lookups are done as for ordinary indexed files.

Alternatively, the table can be provided as a regular-expression map where patterns are given as regular expressions. In this case, the lookups are done in a slightly different way as described below under "REGULAR EXPRESSION TABLES".

Users can control delivery of their own mail by setting up .forward files in their home directory. Lines in per-user .forward files have the same syntax as the right-hand side of aliases(5) entries.

The format of the alias database input file is as follows:

- An alias definition has the form

```
     name: value1, value2, ...
```

- Empty lines and whitespace-only lines are ignored, as are lines whose first non-whitespace character is a `#'.

- A logical line starts with non-whitespace text. A line that starts with whitespace continues a logical line.

The name is a local address (no domain part). Use double quotes when the name contains any special characters such as whitespace, `#', `:', or `@'. The name is folded to lowercase, in order to make database lookups case insensitive.

In addition, when an alias exists for owner-name, this will override the envelope sender address, so that delivery diagnostics are directed to owner-name, instead of the originator of the message (for details, see owner_request_special, expand_owner_alias and reset_owner_alias). This is typically used to direct delivery errors to the maintainer of a mailing list, who is in a better position to deal with mailing list delivery problems than the originator of the undelivered mail.

The value contains one or more of the following:

address

Mail is forwarded to address, which is compatible with the RFC 822 standard.

/file/name

Mail is appended to /file/name. For details on how a file is written see the sections "EXTERNAL FILE DELIVERY" and "DELIVERY RIGHTS" in the local(8) documentation. Delivery is not limited to regular files. For example, to dispose of unwanted mail, deflect it to /dev/null.

|command

Mail is piped into command. Commands that contain special characters, such as whitespace, should be enclosed between double quotes. For details on how a command is executed see "EXTERNAL COMMAND DELIVERY" and "DELIVERY RIGHTS" in the local(8) documentation. When the command fails, a limited amount of command output is mailed back to the sender. The file /usr/include/sysexits.h defines the expected exit status codes. For example, use "|exit 67" to simulate a "user unknown" error, and "|exit 0" to implement an expensive black hole.

:include:/file/name

Mail is sent to the destinations listed in the named file. Lines in :include: files have the same syntax as the right-hand side of alias entries. A destination can be any destination that is described in this manual page. However, delivery to "|command" and /file/name is disallowed by default. To enable, edit the allow_mail_to_commands and allow_mail_to_files configuration parameters.

## ADDRESS EXTENSION

```

```

When alias database search fails, and the recipient localpart contains the optional recipient delimiter (e.g., user+foo), the search is repeated for the unextended address (e.g., user).

The propagate_unmatched_extensions parameter controls whether an unmatched address extension (+foo) is propagated to the result of table lookup.

## CASE FOLDING

```

```

The local(8) delivery agent always folds the search string to lowercase before database lookup.

## REGULAR EXPRESSION TABLES

```

```

This section describes how the table lookups change when the table is given in the form of regular expressions. For a description of regular expression lookup table syntax, see regexp_table(5) or pcre_table(5). NOTE: these formats do not use ":" at the end of a pattern.

Each regular expression is applied to the entire search string. Thus, a search string user+foo is not broken up into user and foo.

Regular expressions are applied in the order as specified in the table, until a regular expression is found that matches the search string.

Lookup results are the same as with indexed file lookups. For security reasons there is no support for $1, $2 etc. substring interpolation.

## SECURITY

```

```

The local(8) delivery agent disallows regular expression substitution of $1 etc. in alias_maps, because that would open a security hole.

The local(8) delivery agent will silently ignore requests to use the proxymap(8) server within alias_maps. Instead it will open the table directly. Before Postfix version 2.2, the local(8) delivery agent will terminate with a fatal error.

## CONFIGURATION PARAMETERS

```

```

The following main.cf parameters are especially relevant. The text below provides only a parameter summary. See postconf(5) for more details including examples.

alias_database (see 'postconf -d' output)

The alias databases for local(8) delivery that are updated with "newaliases" or with "sendmail -bi".

alias_maps (see 'postconf -d' output)

The alias databases that are used for local(8) delivery.

allow_mail_to_commands (alias, forward)

Restrict local(8) mail delivery to external commands.

allow_mail_to_files (alias, forward)

Restrict local(8) mail delivery to external files.

expand_owner_alias (no)

When delivering to an alias "aliasname" that has an "owner-aliasname" companion alias, set the envelope sender address to the expansion of the "owner-aliasname" alias.

propagate_unmatched_extensions (canonical, virtual)

What address lookup tables copy an address extension from the lookup key to the lookup result.

owner_request_special (yes)

Enable special treatment for owner-listname entries in the aliases(5) file, and don't split owner-listname and listname-request address localparts when the recipient_delimiter is set to "-".

recipient_delimiter (empty)

The set of characters that can separate an email address localpart, user name, or a .forward file name from its extension.

Available in Postfix version 2.3 and later:

frozen_delivered_to (yes)

Update the local(8) delivery agent's idea of the Delivered-To: address (see prepend_delivered_header) only once, at the start of a delivery attempt; do not update the Delivered-To: address while expanding aliases or .forward files.

## STANDARDS

```
RFC 822 (ARPA Internet Text Messages)
```

## SEE ALSO

```
local(8), local delivery agent
newaliases(1), create/update alias database
postalias(1), create/update alias database
postconf(5), configuration parameters
```

## README FILES

```

```

Use "postconf readme_directory" or "postconf html_directory" to locate this information.

```
DATABASE_README, Postfix lookup table overview
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## AUTHOR(S)

```
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
```


bounce

title: bounce(5)

text:
# bounce(5)

## NAME
bounce - Postfix bounce message template format

## SYNOPSIS

```
bounce_template_file = /etc/postfix/bounce.cf
postconf -b [template_file]
```

## DESCRIPTION

The Postfix bounce(8) server produces delivery status notification (DSN) messages for undeliverable mail, delayed mail, successful delivery or address verification requests.

By default, these notifications are generated from built-in templates with message headers and message text. Sites can override the built-in information by specifying a bounce template file with the bounce_template_file configuration parameter.

This document describes the general procedure to create a bounce template file, followed by the specific details of bounce template formats.

## GENERAL PROCEDURE

```

```

To create a customized bounce template file, create a temporary copy of the file /etc/postfix/bounce.cf.default and edit the temporary file.

To preview the results of $name expansions in the template text, use the command

```
    postconf -b temporary_file
```

Errors in the template will be reported to the standard error stream and to the syslog daemon.

While previewing the text, be sure to pay particular attention to the expansion of time value parameters that appear in the delayed mail notification text.

Once the result is satisfactory, copy the template to the Postfix configuration directory and specify in main.cf something like:

```
/etc/postfix/main.cf:

    bounce_template_file = /etc/postfix/bounce.cf
```

## TEMPLATE FILE FORMAT

```

```

The template file can specify templates for failed mail, delayed mail, successful delivery or for address verification. These templates are named failure_template, delay_template, success_template and verify_template, respectively. You can but do not have to specify all four templates in a bounce template file.

Each template starts with "template_name = <<EOF" and ends with a line that contains the word "EOF" only. You can change the word EOF, but you can't enclose it in quotes as with the shell or with Perl (template_name = <<'EOF'). Here is an example:

```
    # The failure template is used for undeliverable mail.

    failure_template = <<EOF

    Charset: us-ascii

    From: MAILER-DAEMON (Mail Delivery System)

    Subject: Undelivered Mail Returned to Sender

    Postmaster-Subject: Postmaster Copy: Undelivered Mail

    This is the mail system at host $myhostname.

    I'm sorry to have to inform you that your message could not

    be delivered to one or more recipients. It's attached below.

    For further assistance, please send mail to postmaster.

    If you do so, please include this problem report. You can

    delete your own text from the attached returned message.

                       The mail system

    EOF
```

The usage and specification of bounce templates is subject to the following restrictions:

- No special meaning is given to the backslash character or to leading whitespace; these are always taken literally.

- Inside the << context, the "$" character is special. To produce a "$" character as output, specify "$$".

- Outside the << context, lines beginning with "#" are ignored, as are empty lines, and lines consisting of whitespace only.

Examples of all templates can be found in the file bounce.cf.default in the Postfix configuration directory.

## TEMPLATE HEADER FORMAT

```

```

The first portion of a bounce template consists of optional template headers. Some become message headers in the delivery status notification; some control the formatting of that notification. Headers not specified in a template will be left at their default value.

The following headers are supported:

Charset:

The MIME character set of the template message text. See the "TEMPLATE MESSAGE TEXT FORMAT" description below.

From:

The sender address in the message header of the delivery status notification.

Subject:

The subject in the message header of the delivery status notification that is returned to the sender.

Postmaster-Subject:

The subject that will be used in Postmaster copies of undeliverable or delayed mail notifications. These copies are sent under control of the notify_classes configuration parameter.

The usage and specification of template message headers is subject to the following restrictions:

- Template message header names can be specified in upper case, lower case or mixed case. Postfix always produces bounce message header labels of the form "From:" and "Subject:".

- Template message headers must not span multiple lines.

- Template message headers do not support $parameter expansions.

- Template message headers must contain ASCII characters only, and must not contain ASCII null characters.

## TEMPLATE MESSAGE TEXT FORMAT

```

```

The second portion of a bounce template consists of message text. As the above example shows, template message text may contain main.cf $parameters. Besides the parameters that are defined in main.cf, the following parameters are treated specially depending on the suffix that is appended to their name.

delay_warning_time_suffix

Expands into the value of the delay_warning_time parameter, expressed in the time unit specified by suffix, which is one of seconds, minutes, hours, days, or weeks.

maximal_queue_lifetime_suffix

Expands into the value of the maximal_queue_lifetime parameter, expressed in the time unit specified by suffix. See above under delay_warning_time for possible suffix values.

mydomain

Expands into the value of the mydomain parameter. With "smtputf8_enable = yes", this replaces ACE labels (xn--mumble) with their UTF-8 equivalent. This feature is available in Postfix 3.0.

myhostname

Expands into the value of the myhostname parameter. With "smtputf8_enable = yes", this replaces ACE labels (xn--mumble) with their UTF-8 equivalent. This feature is available in Postfix 3.0.

The usage and specification of template message text is subject to the following restrictions:

- The template message text is not sent in Postmaster copies of delivery status notifications.

- If the template message text contains non-ASCII characters, Postfix requires that the Charset: template header is updated. Specify an appropriate superset of US-ASCII. A superset is needed because Postfix appends ASCII text after the message template when it sends a delivery status notification.

## SEE ALSO

```
bounce(8), Postfix delivery status notifications
postconf(5), configuration parameters
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## HISTORY

The Postfix bounce template format was originally developed by Nicolas Riendeau.

## AUTHOR(S)

```
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
```


canonical

title: canonical(5)

text:
# canonical(5)

## NAME
canonical - Postfix canonical table format

## SYNOPSIS

```
postmap /etc/postfix/canonical
postmap -q "string" /etc/postfix/canonical
postmap -q - /etc/postfix/canonical <inputfile
```

## DESCRIPTION

The optional canonical(5) table specifies an address mapping for local and non-local addresses. The mapping is used by the cleanup(8) daemon, before mail is stored into the queue. The address mapping is recursive.

Normally, the canonical(5) table is specified as a text file that serves as input to the postmap(1) command. The result, an indexed file in dbm or db format, is used for fast searching by the mail system. Execute the command "postmap /etc/postfix/canonical" to rebuild an indexed file after changing the corresponding text file.

When the table is provided via other means such as NIS, LDAP or SQL, the same lookups are done as for ordinary indexed files.

Alternatively, the table can be provided as a regular-expression map where patterns are given as regular expressions, or lookups can be directed to a TCP-based server. In those cases, the lookups are done in a slightly different way as described below under "REGULAR EXPRESSION TABLES" or "TCP-BASED TABLES".

By default the canonical(5) mapping affects both message header addresses (i.e. addresses that appear inside messages) and message envelope addresses (for example, the addresses that are used in SMTP protocol commands). This is controlled with the canonical_classes parameter.

NOTE: Postfix versions 2.2 and later rewrite message headers from remote SMTP clients only if the client matches the local_header_rewrite_clients parameter, or if the remote_header_rewrite_domain configuration parameter specifies a non-empty value. To get the behavior before Postfix 2.2, specify "local_header_rewrite_clients = static:all".

Typically, one would use the canonical(5) table to replace login names by Firstname.Lastname, or to clean up addresses produced by legacy mail systems.

The canonical(5) mapping is not to be confused with virtual alias support or with local aliasing. To change the destination but not the headers, use the virtual(5) or aliases(5) map instead.

## CASE FOLDING

```

```

The search string is folded to lowercase before database lookup. As of Postfix 2.3, the search string is not case folded with database types such as regexp: or pcre: whose lookup fields can match both upper and lower case.

## TABLE FORMAT

```

```

The input format for the postmap(1) command is as follows:

pattern address

When pattern matches a mail address, replace it by the corresponding address.

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.

## TABLE SEARCH ORDER

```

```

With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, each user@domain query produces a sequence of query patterns as described below.

Each query pattern is sent to each specified lookup table before trying the next query pattern, until a match is found.

user@domain address

Replace user@domain by address. This form has the highest precedence. This is useful to clean up addresses produced by legacy mail systems. It can also be used to produce Firstname.Lastname style addresses, but see below for a simpler solution.

user address

Replace user@site by address when site is equal to $myorigin, when site is listed in $mydestination, or when it is listed in $inet_interfaces or $proxy_interfaces. This form is useful for replacing login names by Firstname.Lastname.

@domain address

Replace other addresses in domain by address. This form has the lowest precedence. Note: @domain is a wild-card. When this form is applied to recipient addresses, the Postfix SMTP server accepts mail for any recipient in domain, regardless of whether that recipient exists. This may turn your mail system into a backscatter source: Postfix first accepts mail for non-existent recipients and then tries to return that mail as "undeliverable" to the often forged sender address.

To avoid backscatter with mail for a wild-card domain, replace the wild-card mapping with explicit 1:1 mappings, or add a reject_unverified_recipient restriction for that domain:

```
    smtpd_recipient_restrictions =

        ...

        reject_unauth_destination

        check_recipient_access

            inline:{example.com=reject_unverified_recipient}

    unverified_recipient_reject_code = 550
```

In the above example, Postfix may contact a remote server if the recipient is rewritten to a remote address.

## RESULT ADDRESS REWRITING

```

```

The lookup result is subject to address rewriting:

- When the result has the form @otherdomain, the result becomes the same user in otherdomain.

- When "append_at_myorigin=yes", append "@$myorigin" to addresses without "@domain".

- When "append_dot_mydomain=yes", append ".$mydomain" to addresses without ".domain".

## ADDRESS EXTENSION

```

```

When a mail address localpart contains the optional recipient delimiter (e.g., user+foo@domain), the lookup order becomes: user+foo@domain, user@domain, user+foo, user, and @domain.

The propagate_unmatched_extensions parameter controls whether an unmatched address extension (+foo) is propagated to the result of table lookup.

## REGULAR EXPRESSION TABLES

```

```

This section describes how the table lookups change when the table is given in the form of regular expressions. For a description of regular expression lookup table syntax, see regexp_table(5) or pcre_table(5).

Each pattern is a regular expression that is applied to the entire address being looked up. Thus, user@domain mail addresses are not broken up into their user and @domain constituent parts, nor is user+foo broken up into user and foo.

Patterns are applied in the order as specified in the table, until a pattern is found that matches the search string.

Results are the same as with indexed file lookups, with the additional feature that parenthesized substrings from the pattern can be interpolated as $1, $2 and so on.

## TCP-BASED TABLES

```

```

This section describes how the table lookups change when lookups are directed to a TCP-based server. For a description of the TCP client/server lookup protocol, see tcp_table(5). This feature is not available up to and including Postfix version 2.4.

Each lookup operation uses the entire address once. Thus, user@domain mail addresses are not broken up into their user and @domain constituent parts, nor is user+foo broken up into user and foo.

Results are the same as with indexed file lookups.

## BUGS

The table format does not understand quoting conventions.

## CONFIGURATION PARAMETERS

```

```

The following main.cf parameters are especially relevant. The text below provides only a parameter summary. See postconf(5) for more details including examples.

canonical_classes (envelope_sender, envelope_recipient, header_sender, header_recipient)

What addresses are subject to canonical_maps address mapping.

canonical_maps (empty)

Optional address mapping lookup tables for message headers and envelopes.

recipient_canonical_maps (empty)

Optional address mapping lookup tables for envelope and header recipient addresses.

sender_canonical_maps (empty)

Optional address mapping lookup tables for envelope and header sender addresses.

propagate_unmatched_extensions (canonical, virtual)

What address lookup tables copy an address extension from the lookup key to the lookup result.

Other parameters of interest:

inet_interfaces (all)

The local network interface addresses that this mail system receives mail on.

local_header_rewrite_clients (permit_inet_interfaces)

Rewrite or add message headers in mail from these clients, updating incomplete addresses with the domain name in $myorigin or $mydomain, and adding missing headers.

proxy_interfaces (empty)

The remote network interface addresses that this mail system receives mail on by way of a proxy or network address translation unit.

masquerade_classes (envelope_sender, header_sender, header_recipient)

What addresses are subject to address masquerading.

masquerade_domains (empty)

Optional list of domains whose subdomain structure will be stripped off in email addresses.

masquerade_exceptions (empty)

Optional list of user names that are not subjected to address masquerading, even when their addresses match $masquerade_domains.

mydestination ($myhostname, localhost.$mydomain, localhost, $config_directory/mydestination)

The list of domains that are delivered via the $local_transport mail delivery transport.

myorigin ($myhostname)

The domain name that locally-posted mail appears to come from, and that locally posted mail is delivered to.

owner_request_special (yes)

Enable special treatment for owner-listname entries in the aliases(5) file, and don't split owner-listname and listname-request address localparts when the recipient_delimiter is set to "-".

remote_header_rewrite_domain (empty)

Rewrite or add message headers in mail from remote clients if the remote_header_rewrite_domain parameter value is non-empty, updating incomplete addresses with the domain specified in the remote_header_rewrite_domain parameter, and adding missing headers.

## SEE ALSO

```
cleanup(8), canonicalize and enqueue mail
postmap(1), Postfix lookup table manager
postconf(5), configuration parameters
virtual(5), virtual aliasing
```

## README FILES

```

```

Use "postconf readme_directory" or "postconf html_directory" to locate this information.

```
DATABASE_README, Postfix lookup table overview
ADDRESS_REWRITING_README, address rewriting guide
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## AUTHOR(S)

```
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
```


title: cidr_table(5)

text:
# cidr_table(5)

## NAME
cidr_table - format of Postfix CIDR tables

## SYNOPSIS

```
postmap -q "string" cidr:/etc/postfix/filename
postmap -q - cidr:/etc/postfix/filename <inputfile
```

## DESCRIPTION

The Postfix mail system uses optional lookup tables. These tables are usually in dbm or db format. Alternatively, lookup tables can be specified in CIDR (Classless Inter-Domain Routing) form. In this case, each input is compared against a list of patterns. 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.

## TABLE FORMAT

```

```

The general form of a Postfix CIDR table is:

pattern result

When a search string matches the specified pattern, use the corresponding result value. The pattern must be in network/prefix or network_address form (see ADDRESS PATTERN SYNTAX below).

!pattern result

When a search string does not match the specified pattern, use the specified result value. The pattern must be in network/prefix or network_address form (see ADDRESS PATTERN SYNTAX below). This feature is available in Postfix 3.2 and later.

if pattern

endif

When a search string matches the specified pattern, match that search string against the patterns between if and endif. The pattern must be in network/prefix or network_address form (see ADDRESS PATTERN SYNTAX below). The if..endif can nest. Note: do not prepend whitespace to text between if..endif.

This feature is available in Postfix 3.2 and later.

if !pattern

endif

When a search string does not match the specified pattern, match that search string against the patterns between if and endif. The pattern must be in network/prefix or network_address form (see ADDRESS PATTERN SYNTAX below). The if..endif can nest. Note: do not prepend whitespace to text between if..endif.

This feature is available in Postfix 3.2 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.

## TABLE SEARCH ORDER

```

```

Patterns are applied in the order as specified in the table, until a pattern is found that matches the search string.

## ADDRESS PATTERN SYNTAX

```

```

Postfix CIDR tables are pattern-based. A pattern is either a network_address which requires an exact match, or a network_address/prefix_length where the prefix_length part specifies the length of the network_address prefix that must be matched (the other bits in the network_address part must be zero).

An IPv4 network address is a sequence of four decimal octets separated by ".", and an IPv6 network address is a sequence of three to eight hexadecimal octet pairs separated by ":" or "::", where the latter is short-hand for a sequence of one or more all-zero octet pairs. The pattern 0.0.0.0/0 matches every IPv4 address, and ::/0 matches every IPv6 address. IPv6 support is available in Postfix 2.2 and later.

Before comparisons are made, lookup keys and table entries are converted from string to binary. Therefore, IPv6 patterns will be matched regardless of leading zeros (a leading zero in an IPv4 address octet indicates octal notation).

Note: address information may be enclosed inside "[]" but this form is not required.

## 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 = .. cidr:{ { rule-1 }, { rule-2 } .. } ..
master.cf:

    .. -o { parameter = .. cidr:{ { rule-1 }, { rule-2 } .. } .. } ..
```

Postfix 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 /etc/postfix.

Note: if a rule contains $, specify $$ to keep Postfix from trying to do $name expansion as it evaluates a parameter value.

## EXAMPLE SMTPD ACCESS MAP

```
/etc/postfix/main.cf:

    smtpd_client_restrictions = ... cidr:/etc/postfix/client.cidr ...
/etc/postfix/client.cidr:

    # Rule order matters. Put more specific allowlist entries

    # before more general denylist entries.

    192.168.1.1             OK

    192.168.0.0/16          REJECT

    2001:db8::1             OK

    2001:db8::/32           REJECT
```

## SEE ALSO

```
postmap(1), Postfix lookup table manager
regexp_table(5), format of regular expression tables
pcre_table(5), format of PCRE tables
```

## README FILES

```

```

Use "postconf readme_directory" or "postconf html_directory" to locate this information.

```
DATABASE_README, Postfix lookup table overview
```

## HISTORY

CIDR table support was introduced with Postfix version 2.1.

## AUTHOR(S)

```
The CIDR table lookup code was originally written by:
Jozsef Kadlecsik
KFKI Research Institute for Particle and Nuclear Physics
POB. 49
1525 Budapest, Hungary
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
```


generic

title: generic(5)

text:
# generic(5)

## NAME
generic - Postfix generic table format

## SYNOPSIS

```
postmap /etc/postfix/generic
postmap -q "string" /etc/postfix/generic
postmap -q - /etc/postfix/generic <inputfile
```

## DESCRIPTION

The optional generic(5) table specifies an address mapping that applies when mail is delivered. This is the opposite of canonical(5) mapping, which applies when mail is received.

Typically, one would use the generic(5) table on a system that does not have a valid Internet domain name and that uses something like localdomain.local instead. The generic(5) table is then used by the smtp(8) client to transform local mail addresses into valid Internet mail addresses when mail has to be sent across the Internet. See the EXAMPLE section at the end of this document.

The generic(5) mapping affects both message header addresses (i.e. addresses that appear inside messages) and message envelope addresses (for example, the addresses that are used in SMTP protocol commands).

Normally, the generic(5) table is specified as a text file that serves as input to the postmap(1) command. The result, an indexed file in dbm or db format, is used for fast searching by the mail system. Execute the command "postmap /etc/postfix/generic" to rebuild an indexed file after changing the corresponding text file.

When the table is provided via other means such as NIS, LDAP or SQL, the same lookups are done as for ordinary indexed files.

Alternatively, the table can be provided as a regular-expression map where patterns are given as regular expressions, or lookups can be directed to a TCP-based server. In those cases, the lookups are done in a slightly different way as described below under "REGULAR EXPRESSION TABLES" or "TCP-BASED TABLES".

## CASE FOLDING

```

```

The search string is folded to lowercase before database lookup. As of Postfix 2.3, the search string is not case folded with database types such as regexp: or pcre: whose lookup fields can match both upper and lower case.

## TABLE FORMAT

```

```

The input format for the postmap(1) command is as follows:

pattern result

When pattern matches a mail address, replace it by the corresponding result.

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.

## TABLE SEARCH ORDER

```

```

With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, each user@domain query produces a sequence of query patterns as described below.

Each query pattern is sent to each specified lookup table before trying the next query pattern, until a match is found.

user@domain address

Replace user@domain by address. This form has the highest precedence.

user address

Replace user@site by address when site is equal to $myorigin, when site is listed in $mydestination, or when it is listed in $inet_interfaces or $proxy_interfaces.

@domain address

Replace other addresses in domain by address. This form has the lowest precedence.

## RESULT ADDRESS REWRITING

```

```

The lookup result is subject to address rewriting:

- When the result has the form @otherdomain, the result becomes the same user in otherdomain.

- When "append_at_myorigin=yes", append "@$myorigin" to addresses without "@domain".

- When "append_dot_mydomain=yes", append ".$mydomain" to addresses without ".domain".

## ADDRESS EXTENSION

```

```

When a mail address localpart contains the optional recipient delimiter (e.g., user+foo@domain), the lookup order becomes: user+foo@domain, user@domain, user+foo, user, and @domain.

The propagate_unmatched_extensions parameter controls whether an unmatched address extension (+foo) is propagated to the result of table lookup.

## REGULAR EXPRESSION TABLES

```

```

This section describes how the table lookups change when the table is given in the form of regular expressions. For a description of regular expression lookup table syntax, see regexp_table(5) or pcre_table(5).

Each pattern is a regular expression that is applied to the entire address being looked up. Thus, user@domain mail addresses are not broken up into their user and @domain constituent parts, nor is user+foo broken up into user and foo.

Patterns are applied in the order as specified in the table, until a pattern is found that matches the search string.

Results are the same as with indexed file lookups, with the additional feature that parenthesized substrings from the pattern can be interpolated as $1, $2 and so on.

## TCP-BASED TABLES

```

```

This section describes how the table lookups change when lookups are directed to a TCP-based server. For a description of the TCP client/server lookup protocol, see tcp_table(5). This feature is available in Postfix 2.5 and later.

Each lookup operation uses the entire address once. Thus, user@domain mail addresses are not broken up into their user and @domain constituent parts, nor is user+foo broken up into user and foo.

Results are the same as with indexed file lookups.

## EXAMPLE

```

```

The following shows a generic mapping with an indexed file. When mail is sent to a remote host via SMTP, this replaces his@localdomain.local by his ISP mail address, replaces her@localdomain.local by her ISP mail address, and replaces other local addresses by his ISP account, with an address extension of +local (this example assumes that the ISP supports "+" style address extensions).

```
/etc/postfix/main.cf:

    smtp_generic_maps = hash:/etc/postfix/generic
/etc/postfix/generic:

    his@localdomain.local   hisaccount@hisisp.example

    her@localdomain.local   heraccount@herisp.example

    @localdomain.local      hisaccount+local@hisisp.example
```

Execute the command "postmap /etc/postfix/generic" whenever the table is changed. Instead of hash, some systems use dbm database files. To find out what tables your system supports use the command "postconf -m".

## BUGS

The table format does not understand quoting conventions.

## CONFIGURATION PARAMETERS

```

```

The following main.cf parameters are especially relevant. The text below provides only a parameter summary. See postconf(5) for more details including examples.

smtp_generic_maps (empty)

Optional lookup tables that perform address rewriting in the Postfix SMTP client, typically to transform a locally valid address into a globally valid address when sending mail across the Internet.

propagate_unmatched_extensions (canonical, virtual)

What address lookup tables copy an address extension from the lookup key to the lookup result.

Other parameters of interest:

inet_interfaces (all)

The local network interface addresses that this mail system receives mail on.

proxy_interfaces (empty)

The remote network interface addresses that this mail system receives mail on by way of a proxy or network address translation unit.

mydestination ($myhostname, localhost.$mydomain, localhost, $config_directory/mydestination)

The list of domains that are delivered via the $local_transport mail delivery transport.

myorigin ($myhostname)

The domain name that locally-posted mail appears to come from, and that locally posted mail is delivered to.

owner_request_special (yes)

Enable special treatment for owner-listname entries in the aliases(5) file, and don't split owner-listname and listname-request address localparts when the recipient_delimiter is set to "-".

## SEE ALSO

```
postmap(1), Postfix lookup table manager
postconf(5), configuration parameters
smtp(8), Postfix SMTP client
```

## README FILES

```

```

Use "postconf readme_directory" or "postconf html_directory" to locate this information.

```
ADDRESS_REWRITING_README, address rewriting guide
DATABASE_README, Postfix lookup table overview
STANDARD_CONFIGURATION_README, configuration examples
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## HISTORY

A genericstable feature appears in the Sendmail MTA.

This feature is available in Postfix 2.2 and later.

## AUTHOR(S)

```
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
```


title: header_checks(5)

text:
# header_checks(5)

## NAME
header_checks - Postfix built-in content inspection

## SYNOPSIS

```
header_checks = pcre:/etc/postfix/header_checks
mime_header_checks = pcre:/etc/postfix/mime_header_checks
nested_header_checks = pcre:/etc/postfix/nested_header_checks
body_checks = pcre:/etc/postfix/body_checks

milter_header_checks = pcre:/etc/postfix/milter_header_checks

smtp_header_checks = pcre:/etc/postfix/smtp_header_checks
smtp_mime_header_checks = pcre:/etc/postfix/smtp_mime_header_checks
smtp_nested_header_checks = pcre:/etc/postfix/smtp_nested_header_checks
smtp_body_checks = pcre:/etc/postfix/smtp_body_checks

postmap -q "string" pcre:/etc/postfix/filename
postmap -q - pcre:/etc/postfix/filename <inputfile
```

## DESCRIPTION

This document describes access control on the content of message headers and message body lines; it is implemented by the Postfix cleanup(8) server before mail is queued. See access(5) for access control on remote SMTP client information.

Each message header or message body line is compared against a list of patterns. When a match is found the corresponding action is executed, and the matching process is repeated for the next message header or message body line.

Note: message headers are examined one logical header at a time, even when a message header spans multiple lines. Body lines are always examined one line at a time.

For examples, see the EXAMPLES section at the end of this manual page.

Postfix header or body_checks are designed to stop a flood of mail from worms or viruses; they do not decode attachments, and they do not unzip archives. See the documents referenced below in the README FILES section if you need more sophisticated content analysis.

## FILTERS WHILE RECEIVING MAIL

```

```

Postfix implements the following four built-in content inspection classes while receiving mail:

header_checks (default: empty)

These are applied to initial message headers (except for the headers that are processed with mime_header_checks).

mime_header_checks (default: $header_checks)

These are applied to MIME related message headers only. This feature is available in Postfix 2.0 and later.

nested_header_checks (default: $header_checks)

These are applied to message headers of attached email messages (except for the headers that are processed with mime_header_checks). This feature is available in Postfix 2.0 and later.

body_checks

These are applied to all other content, including multi-part message boundaries. With Postfix versions before 2.0, all content after the initial message headers is treated as body content.

## FILTERS AFTER RECEIVING MAIL

```

```

Postfix supports a subset of the built-in content inspection classes after the message is received:

milter_header_checks (default: empty)

These are applied to headers that are added with Milter applications. This feature is available in Postfix 2.7 and later.

## FILTERS WHILE DELIVERING MAIL

```

```

Postfix supports all four content inspection classes while delivering mail via SMTP.

smtp_header_checks (default: empty)

smtp_mime_header_checks (default: empty)

smtp_nested_header_checks (default: empty)

smtp_body_checks (default: empty)

These features are available in Postfix 2.5 and later.

## COMPATIBILITY

```

```

With Postfix version 2.2 and earlier specify "postmap -fq" to query a table that contains case sensitive patterns. By default, regexp: and pcre: patterns are case insensitive.

## TABLE FORMAT

```

```

This document assumes that header and body_checks rules are specified in the form of Postfix regular expression lookup tables. Usually the best performance is obtained with pcre (Perl Compatible Regular Expression) tables. The regexp (POSIX regular expressions) tables are usually slower, but more widely available. Use the command "postconf -m" to find out what lookup table types your Postfix system supports.

The general format of Postfix regular expression tables is given below. For a discussion of specific pattern or flags syntax, see pcre_table(5) or regexp_table(5), respectively.

/pattern/flags action

When /pattern/ matches the input string, execute the corresponding action. See below for a list of possible actions.

!/pattern/flags action

When /pattern/ does not match the input string, execute the corresponding action.

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.

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.

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 pattern/action line starts with non-whitespace text. A line that starts with whitespace continues a logical line.

## TABLE SEARCH ORDER

```

```

For each line of message input, the patterns are applied in the order as specified in the table. When a pattern is found that matches the input line, the corresponding action is executed and then the next input line is inspected.

## TEXT SUBSTITUTION

```

```

Substitution of substrings from the matched expression into the action string is possible using the conventional Perl syntax ($1, $2, etc.). 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.

## ACTIONS

```

```

Action names are case insensitive. They are shown in upper case for consistency with other Postfix documentation.

BCC user@domain

Add the specified address as a BCC recipient, and inspect the next input line. The address must have a local part and domain part. The number of BCC addresses that can be added is limited only by the amount of available storage space. Note 1: the BCC address is added as if it was specified with NOTIFY=NONE. The sender will not be notified when the BCC address is undeliverable, as long as all down-stream software implements RFC 3461.

Note 2: this ignores duplicate addresses (with the same delivery status notification options).

This feature is available in Postfix 3.0 and later.

This feature is not supported with smtp header/body checks.

DISCARD optional text...

Claim successful delivery and silently discard the message. Do not inspect the remainder of the input message. Log the optional text if specified, otherwise log a generic message. Note: this action disables further header or body_checks inspection of the current message and affects all recipients. To discard only one recipient without discarding the entire message, use the transport(5) table to direct mail to the discard(8) service.

This feature is available in Postfix 2.0 and later.

This feature is not supported with smtp header/body checks.

DUNNO

Pretend that the input line did not match any pattern, and inspect the next input line. This action can be used to shorten the table search. For backwards compatibility reasons, Postfix also accepts OK but it is (and always has been) treated as DUNNO.

This feature is available in Postfix 2.1 and later.

FILTER transport:destination

Override the content_filter parameter setting, and inspect the next input line. After the message is queued, send the entire message through the specified external content filter. The transport name specifies the first field of a mail delivery agent definition in master.cf; the syntax of the next-hop destination is described in the manual page of the corresponding delivery agent. More information about external content filters is in the Postfix FILTER_README file. Note 1: do not use $number regular expression substitutions for transport or destination unless you know that the information has a trusted origin.

Note 2: this action overrides the main.cf content_filter setting, and affects all recipients of the message. In the case that multiple FILTER actions fire, only the last one is executed.

Note 3: the purpose of the FILTER command is to override message routing. To override the recipient's transport but not the next-hop destination, specify an empty filter destination (Postfix 2.7 and later), or specify a transport:destination that delivers through a different Postfix instance (Postfix 2.6 and earlier). Other options are using the recipient-dependent transport_maps or the sender-dependent sender_dependent_default_transport_maps features.

This feature is available in Postfix 2.0 and later.

This feature is not supported with smtp header/body checks.

HOLD optional text...

Arrange for the message to be placed on the hold queue, and inspect the next input line. The message remains on hold until someone either deletes it or releases it for delivery. Log the optional text if specified, otherwise log a generic message. Mail that is placed on hold can be examined with the postcat(1) command, and can be destroyed or released with the postsuper(1) command.

Note: use "postsuper -r" to release mail that was kept on hold for a significant fraction of $maximal_queue_lifetime or $bounce_queue_lifetime, or longer. Use "postsuper -H" only for mail that will not expire within a few delivery attempts.

Note: this action affects all recipients of the message.

This feature is available in Postfix 2.0 and later.

This feature is not supported with smtp header/body checks.

IGNORE

Delete the current line from the input, and inspect the next input line. See STRIP for an alternative that logs the action.

INFO optional text...

Log an "info:" record with the optional text... (or log a generic text), and inspect the next input line. This action is useful for routine logging or for debugging. This feature is available in Postfix 2.8 and later.

PASS optional text...

Log a "pass:" record with the optional text... (or log a generic text), and turn off header, body, and Milter inspection for the remainder of this message. Note: this feature relies on trust in information that is easy to forge.

This feature is available in Postfix 3.2 and later.

This feature is not supported with smtp header/body checks.

PREPEND text...

Prepend one line with the specified text, and inspect the next input line. Notes:

- The prepended text is output on a separate line, immediately before the input that triggered the PREPEND action.

- The prepended text is not considered part of the input stream: it is not subject to header/body checks or address rewriting, and it does not affect the way that Postfix adds missing message headers.

- When prepending text before a message header line, the prepended text must begin with a valid message header label.

- This action cannot be used to prepend multi-line text.

This feature is available in Postfix 2.1 and later. This feature is not supported with milter_header_checks.

REDIRECT user@domain

Write a message redirection request to the queue file, and inspect the next input line. After the message is queued, it will be sent to the specified address instead of the intended recipient(s). Note: this action overrides the FILTER action, and affects all recipients of the message. If multiple REDIRECT actions fire, only the last one is executed.

This feature is available in Postfix 2.1 and later.

This feature is not supported with smtp header/body checks.

REPLACE text...

Replace the current line with the specified text, and inspect the next input line. This feature is available in Postfix 2.2 and later. The description below applies to Postfix 2.2.2 and later.

Notes:

- When replacing a message header line, the replacement text must begin with a valid header label.

- The replaced text remains part of the input stream. Unlike the result from the PREPEND action, a replaced message header may be subject to address rewriting and may affect the way that Postfix adds missing message headers.

REJECT optional text...

Reject the entire message. Do not inspect the remainder of the input message. Reply with optional text... when the optional text is specified, otherwise reply with a generic error message. Note: this action disables further header or body_checks inspection of the current message and affects all recipients.

Postfix version 2.3 and later support enhanced status codes. When no code is specified at the beginning of optional text..., Postfix inserts a default enhanced status code of "5.7.1".

This feature is not supported with smtp header/body checks.

STRIP optional text...

Log a "strip:" record with the optional text... (or log a generic text), delete the input line from the input, and inspect the next input line. See IGNORE for a silent alternative. This feature is available in Postfix 3.2 and later.

WARN optional text...

Log a "warning:" record with the optional text... (or log a generic text), and inspect the next input line. This action is useful for debugging and for testing a pattern before applying more drastic actions.

## BUGS

Empty lines never match, because some map types mis-behave when given a zero-length search string. This limitation may be removed for regular expression tables in a future release.

Many people overlook the main limitations of header and body_checks rules.

- These rules operate on one logical message header or one body line at a time. A decision made for one line is not carried over to the next line.

- If text in the message body is encoded (RFC 2045) then the rules need to be specified for the encoded form.

- Likewise, when message headers are encoded (RFC 2047) then the rules need to be specified for the encoded form.

Message headers added by the cleanup(8) daemon itself are excluded from inspection. Examples of such message headers are From:, To:, Message-ID:, Date:.

Message headers deleted by the cleanup(8) daemon will be examined before they are deleted. Examples are: Bcc:, Content-Length:, Return-Path:.

## CONFIGURATION PARAMETERS

```

```

body_checks (empty)

Optional lookup tables for content inspection as specified in the body_checks(5) manual page.

body_checks_size_limit (51200)

How much text in a message body segment (or attachment, if you prefer to use that term) is subjected to body_checks inspection.

header_checks (empty)

Optional lookup tables for content inspection of primary non-MIME message headers, as specified in the header_checks(5) manual page.

mime_header_checks ($header_checks)

Optional lookup tables for content inspection of MIME related message headers, as described in the header_checks(5) manual page.

nested_header_checks ($header_checks)

Optional lookup tables for content inspection of non-MIME message headers in attached messages, as described in the header_checks(5) manual page.

disable_mime_input_processing (no)

Turn off MIME processing while receiving mail.

## EXAMPLES

```

```

Header pattern to block attachments with bad file name extensions. For convenience, the PCRE /x flag is specified, so that there is no need to collapse the pattern into a single line of text. The purpose of the [[:xdigit:]] sub-expressions is to recognize Windows CLSID strings.

```
/etc/postfix/main.cf:

    header_checks = pcre:/etc/postfix/header_checks.pcre
/etc/postfix/header_checks.pcre:

    /^Content-(Disposition|Type).*name\s*=\s*"?([^;]*(\.|=2E)(

      ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|

      hlp|ht[at]|

      inf|ins|isp|jse?|lnk|md[betw]|ms[cipt]|nws|

      \{[[:xdigit:]]{8}(?:-[[:xdigit:]]{4}){3}-[[:xdigit:]]{12}\}|

      ops|pcd|pif|prf|reg|sc[frt]|sh[bsm]|swf|

      vb[esx]?|vxd|ws[cfh]))(\?=)?"?\s*(;|$)/x

        REJECT Attachment name "$2" may not end with ".$4"
```

Body pattern to stop a specific HTML browser vulnerability exploit.

```
/etc/postfix/main.cf:

    body_checks = regexp:/etc/postfix/body_checks
/etc/postfix/body_checks:

    /^<iframe src=(3D)?cid:.* height=(3D)?0 width=(3D)?0>$/

        REJECT IFRAME vulnerability exploit
```

## SEE ALSO

```
cleanup(8), canonicalize and enqueue Postfix message
pcre_table(5), format of PCRE lookup tables
regexp_table(5), format of POSIX regular expression tables
postconf(1), Postfix configuration utility
postmap(1), Postfix lookup table management
postsuper(1), Postfix janitor
postcat(1), show Postfix queue file contents
RFC 2045, base64 and quoted-printable encoding rules
RFC 2047, message header encoding for non-ASCII text
```

## README FILES

```

```

Use "postconf readme_directory" or "postconf html_directory" to locate this information.

```
DATABASE_README, Postfix lookup table overview
CONTENT_INSPECTION_README, Postfix content inspection overview
BUILTIN_FILTER_README, Postfix built-in content inspection
BACKSCATTER_README, blocking returned forged mail
```

## LICENSE

```

```

The Secure Mailer license must be distributed with this software.

## AUTHOR(S)

```
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
```