or the command must be invoked with root priveleges. This
mitigates a problem with the PHP mail() function. Files:
global/mail_conf.[hc], sendmail/sendmail.c.
+
+20161228
+
+ Documentation: moved the "BACKWARDS COMPATIBILITY" sections
+ to the end of ldap_table, mysql_table, pgsql_table, and
+ sqlite_table, renamed to "OBSOLETE MAIN.CF PARAMETERS".
+
+20161231
+
+ Bugfix (introduced: 20160521): segfault (null pointer) in
+ cidr, pcre, and regexp table when an input does not match
+ an ENDIF-less IF operator. Found during code maintenance.
+ File: util/cidr_map.c, util/dict_regexp.c, util/dict_pcre.c.
example is given at the end of this manual.
This configuration method is available with Postfix version 2.1 and
- later. See the section "BACKWARDS COMPATIBILITY" below for older Post-
- fix versions.
+ later. See the section "OBSOLETE MAIN.CF PARAMETERS" below for older
+ Postfix versions.
For details about LDAP SSL and STARTTLS, see the section on SSL and
STARTTLS below.
-<b>BACKWARDS COMPATIBILITY</b>
- For backwards compatibility with Postfix version 2.0 and earlier, LDAP
- parameters can also be defined in <a href="postconf.5.html">main.cf</a>. Specify as LDAP source a
- name that doesn't begin with a slash or a dot. The LDAP parameters
- will then be accessible as the name you've given the source in its def-
- inition, an underscore, and the name of the parameter. For example, if
- the map is specified as "<a href="ldap_table.5.html">ldap</a>:<i>ldapsource</i>", the "server_host" parameter
- below would be defined in <a href="postconf.5.html">main.cf</a> as "<i>ldapsource</i>_server_host".
-
- Note: with this form, the passwords for the LDAP sources are written in
- <a href="postconf.5.html">main.cf</a>, which is normally world-readable. Support for this form will
- be removed in a future Postfix version.
-
- For backwards compatibility with the pre 2.2 LDAP clients, <b>result_fil-</b>
- <b>ter</b> can for now be used instead of <b>result_format</b>, when the latter
- parameter is not also set. The new name better reflects the function
- of the parameter. This compatibility interface may be removed in a
- future release.
-
<b>LIST MEMBERSHIP</b>
When using LDAP to store lists such as $<a href="postconf.5.html#mynetworks">mynetworks</a>, $<a href="postconf.5.html#mydestination">mydestination</a>,
$<a href="postconf.5.html#relay_domains">relay_domains</a>, $<a href="postconf.5.html#local_recipient_maps">local_recipient_maps</a>, etc., it is important to under-
list of their maildrops, which will be treated as <a href="http://tools.ietf.org/html/rfc822">RFC822</a> addresses to
which the message will be delivered.
+<b>OBSOLETE MAIN.CF PARAMETERS</b>
+ For backwards compatibility with Postfix version 2.0 and earlier, LDAP
+ parameters can also be defined in <a href="postconf.5.html">main.cf</a>. Specify as LDAP source a
+ name that doesn't begin with a slash or a dot. The LDAP parameters
+ will then be accessible as the name you've given the source in its def-
+ inition, an underscore, and the name of the parameter. For example, if
+ the map is specified as "<a href="ldap_table.5.html">ldap</a>:<i>ldapsource</i>", the "server_host" parameter
+ below would be defined in <a href="postconf.5.html">main.cf</a> as "<i>ldapsource</i>_server_host".
+
+ Note: with this form, the passwords for the LDAP sources are written in
+ <a href="postconf.5.html">main.cf</a>, which is normally world-readable. Support for this form will
+ be removed in a future Postfix version.
+
+<b>OTHER OBSOLETE FEATURES</b>
+ For backwards compatibility with the pre 2.2 LDAP clients, <b>result_fil-</b>
+ <b>ter</b> can for now be used instead of <b>result_format</b>, when the latter
+ parameter is not also set. The new name better reflects the function
+ of the parameter. This compatibility interface may be removed in a
+ future release.
+
<b>SEE ALSO</b>
<a href="postmap.1.html">postmap(1)</a>, Postfix lookup table manager
<a href="postconf.5.html">postconf(5)</a>, configuration parameters
The file /etc/postfix/mysql-aliases.cf has the same format as the Post-
fix <a href="postconf.5.html">main.cf</a> file, and can specify the parameters described below.
-<b>BACKWARDS COMPATIBILITY</b>
- For compatibility with other Postfix lookup tables, MySQL parameters
- can also be defined in <a href="postconf.5.html">main.cf</a>. In order to do that, specify as MySQL
- source a name that doesn't begin with a slash or a dot. The MySQL
- parameters will then be accessible as the name you've given the source
- in its definition, an underscore, and the name of the parameter. For
- example, if the map is specified as "<a href="mysql_table.5.html">mysql</a>:<i>mysqlname</i>", the parameter
- "hosts" below would be defined in <a href="postconf.5.html">main.cf</a> as "<i>mysqlname</i>_hosts".
-
- Note: with this form, the passwords for the MySQL sources are written
- in <a href="postconf.5.html">main.cf</a>, which is normally world-readable. Support for this form
- will be removed in a future Postfix version.
-
- Normally, the SQL query is specified via a single <b>query</b> parameter
- (described in more detail below). When this parameter is not specified
- in the map definition, Postfix reverts to an older interface, with the
- SQL query constructed from the <b>select_field</b>, <b>table</b>, <b>where_field</b> and
- <b>additional_conditions</b> parameters. The old interface will be gradually
- phased out. To migrate to the new interface set:
-
- <b>query</b> = SELECT [<i>select</i><b>_</b><i>field</i>]
- FROM [<i>table</i>]
- WHERE [<i>where</i><b>_</b><i>field</i>] = '%s'
- [<i>additional</i><b>_</b><i>conditions</i>]
-
- Insert the value, not the name, of each legacy parameter. Note that the
- <b>additional_conditions</b> parameter is optional and if not empty, will
- always start with <b>AND</b>.
-
<b>LIST MEMBERSHIP</b>
- When using SQL to store lists such as $<a href="postconf.5.html#mynetworks">mynetworks</a>, $<a href="postconf.5.html#mydestination">mydestination</a>,
- $<a href="postconf.5.html#relay_domains">relay_domains</a>, $<a href="postconf.5.html#local_recipient_maps">local_recipient_maps</a>, etc., it is important to under-
+ When using SQL to store lists such as $<a href="postconf.5.html#mynetworks">mynetworks</a>, $<a href="postconf.5.html#mydestination">mydestination</a>,
+ $<a href="postconf.5.html#relay_domains">relay_domains</a>, $<a href="postconf.5.html#local_recipient_maps">local_recipient_maps</a>, etc., it is important to under-
stand that the table must store each list member as a separate key. The
- table lookup verifies the *existence* of the key. See "Postfix lists
+ table lookup verifies the *existence* of the key. See "Postfix lists
versus tables" in the <a href="DATABASE_README.html">DATABASE_README</a> document for a discussion.
- Do NOT create tables that return the full list of domains in $<a href="postconf.5.html#mydestination">mydesti</a>-
+ Do NOT create tables that return the full list of domains in $<a href="postconf.5.html#mydestination">mydesti</a>-
<a href="postconf.5.html#mydestination">nation</a> or $<a href="postconf.5.html#relay_domains">relay_domains</a> etc., or IP addresses in $<a href="postconf.5.html#mynetworks">mynetworks</a>.
DO create tables with each matching item as a key and with an arbitrary
- value. With SQL databases it is not uncommon to return the key itself
+ value. With SQL databases it is not uncommon to return the key itself
or a constant value.
<b>MYSQL PARAMETERS</b>
- <b>hosts</b> The hosts that Postfix will try to connect to and query from.
+ <b>hosts</b> The hosts that Postfix will try to connect to and query from.
Specify <i>unix:</i> for UNIX domain sockets, <i>inet:</i> for TCP connections
(default). Example:
hosts = host1.some.domain host2.some.domain:port
hosts = unix:/file/name
- The hosts are tried in random order, with all connections over
+ The hosts are tried in random order, with all connections over
UNIX domain sockets being tried before those over TCP. The con-
- nections are automatically closed after being idle for about 1
+ nections are automatically closed after being idle for about 1
minute, and are re-opened as necessary. Postfix versions 2.0 and
earlier do not randomize the host order.
NOTE: if you specify localhost as a hostname (even if you prefix
- it with <i>inet:</i>), MySQL will connect to the default UNIX domain
+ it with <i>inet:</i>), MySQL will connect to the default UNIX domain
socket. In order to instruct MySQL to connect to localhost over
TCP you have to specify
hosts = 127.0.0.1
<b>user, password</b>
- The user name and password to log into the mysql server. Exam-
+ The user name and password to log into the mysql server. Exam-
ple:
user = someone
password = some_password
<b>dbname</b> The database name on the servers. Example:
dbname = customer_database
- <b>query</b> The SQL query template used to search the database, where <b>%s</b> is
- a substitute for the address Postfix is trying to resolve, e.g.
+ <b>query</b> The SQL query template used to search the database, where <b>%s</b> is
+ a substitute for the address Postfix is trying to resolve, e.g.
query = SELECT replacement FROM aliases WHERE mailbox = '%s'
- By default, every query must return a result set (instead of
- storing its results in a table); with "<b>require_result_set = no</b>"
- (Postfix 3.2 and later), the absence of a result set is treated
+ By default, every query must return a result set (instead of
+ storing its results in a table); with "<b>require_result_set = no</b>"
+ (Postfix 3.2 and later), the absence of a result set is treated
as "not found".
This parameter supports the following '%' expansions:
<b>%%</b> This is replaced by a literal '%' character.
- <b>%s</b> This is replaced by the input key. SQL quoting is used
- to make sure that the input key does not add unexpected
+ <b>%s</b> This is replaced by the input key. SQL quoting is used
+ to make sure that the input key does not add unexpected
metacharacters.
<b>%u</b> When the input key is an address of the form user@domain,
- <b>%u</b> is replaced by the SQL quoted local part of the
- address. Otherwise, <b>%u</b> is replaced by the entire search
- string. If the localpart is empty, the query is sup-
+ <b>%u</b> is replaced by the SQL quoted local part of the
+ address. Otherwise, <b>%u</b> is replaced by the entire search
+ string. If the localpart is empty, the query is sup-
pressed and returns no results.
<b>%d</b> When the input key is an address of the form user@domain,
- <b>%d</b> is replaced by the SQL quoted domain part of the
- address. Otherwise, the query is suppressed and returns
+ <b>%d</b> is replaced by the SQL quoted domain part of the
+ address. Otherwise, the query is suppressed and returns
no results.
<b>%[SUD]</b> The upper-case equivalents of the above expansions behave
- in the <b>query</b> parameter identically to their lower-case
- counter-parts. With the <b>result_format</b> parameter (see
- below), they expand the input key rather than the result
+ in the <b>query</b> parameter identically to their lower-case
+ counter-parts. With the <b>result_format</b> parameter (see
+ below), they expand the input key rather than the result
value.
- <b>%[1-9]</b> The patterns %1, %2, ... %9 are replaced by the corre-
- sponding most significant component of the input key's
- domain. If the input key is <i>user@mail.example.com</i>, then
+ <b>%[1-9]</b> The patterns %1, %2, ... %9 are replaced by the corre-
+ sponding most significant component of the input key's
+ domain. If the input key is <i>user@mail.example.com</i>, then
%1 is <b>com</b>, %2 is <b>example</b> and %3 is <b>mail</b>. If the input key
- is unqualified or does not have enough domain components
- to satisfy all the specified patterns, the query is sup-
+ is unqualified or does not have enough domain components
+ to satisfy all the specified patterns, the query is sup-
pressed and returns no results.
- The <b>domain</b> parameter described below limits the input keys to
- addresses in matching domains. When the <b>domain</b> parameter is
+ The <b>domain</b> parameter described below limits the input keys to
+ addresses in matching domains. When the <b>domain</b> parameter is
non-empty, SQL queries for unqualified addresses or addresses in
non-matching domains are suppressed and return no results.
- This parameter is available with Postfix 2.2. In prior releases
- the SQL query was built from the separate parameters:
- <b>select_field</b>, <b>table</b>, <b>where_field</b> and <b>additional_conditions</b>. The
+ This parameter is available with Postfix 2.2. In prior releases
+ the SQL query was built from the separate parameters:
+ <b>select_field</b>, <b>table</b>, <b>where_field</b> and <b>additional_conditions</b>. The
mapping from the old parameters to the equivalent query is:
SELECT [<b>select_field</b>]
WHERE [<b>where_field</b>] = '%s'
[<b>additional_conditions</b>]
- The '%s' in the <b>WHERE</b> clause expands to the escaped search
- string. With Postfix 2.2 these legacy parameters are used if
+ The '%s' in the <b>WHERE</b> clause expands to the escaped search
+ string. With Postfix 2.2 these legacy parameters are used if
the <b>query</b> parameter is not specified.
NOTE: DO NOT put quotes around the query parameter.
<b>result_format (default: %s</b>)
Format template applied to result attributes. Most commonly used
- to append (or prepend) text to the result. This parameter sup-
+ to append (or prepend) text to the result. This parameter sup-
ports the following '%' expansions:
<b>%%</b> This is replaced by a literal '%' character.
- <b>%s</b> This is replaced by the value of the result attribute.
+ <b>%s</b> This is replaced by the value of the result attribute.
When result is empty it is skipped.
<b>%u</b> When the result attribute value is an address of the form
- user@domain, <b>%u</b> is replaced by the local part of the
- address. When the result has an empty localpart it is
+ user@domain, <b>%u</b> is replaced by the local part of the
+ address. When the result has an empty localpart it is
skipped.
- <b>%d</b> When a result attribute value is an address of the form
- user@domain, <b>%d</b> is replaced by the domain part of the
- attribute value. When the result is unqualified it is
+ <b>%d</b> When a result attribute value is an address of the form
+ user@domain, <b>%d</b> is replaced by the domain part of the
+ attribute value. When the result is unqualified it is
skipped.
<b>%[SUD1-9]</b>
- The upper-case and decimal digit expansions interpolate
- the parts of the input key rather than the result. Their
- behavior is identical to that described with <b>query</b>, and
- in fact because the input key is known in advance,
- queries whose key does not contain all the information
- specified in the result template are suppressed and
+ The upper-case and decimal digit expansions interpolate
+ the parts of the input key rather than the result. Their
+ behavior is identical to that described with <b>query</b>, and
+ in fact because the input key is known in advance,
+ queries whose key does not contain all the information
+ specified in the result template are suppressed and
return no results.
For example, using "result_format = <a href="smtp.8.html">smtp</a>:[%s]" allows one to use
a mailHost attribute as the basis of a <a href="transport.5.html">transport(5)</a> table. After
- applying the result format, multiple values are concatenated as
+ applying the result format, multiple values are concatenated as
comma separated strings. The expansion_limit and parameter
- explained below allows one to restrict the number of values in
+ explained below allows one to restrict the number of values in
the result, which is especially useful for maps that must return
at most one value.
- The default value <b>%s</b> specifies that each result value should be
+ The default value <b>%s</b> specifies that each result value should be
used as is.
This parameter is available with Postfix 2.2 and later.
<b>domain (default: no domain list)</b>
This is a list of domain names, paths to files, or dictionaries.
- When specified, only fully qualified search keys with a
- *non-empty* localpart and a matching domain are eligible for
+ When specified, only fully qualified search keys with a
+ *non-empty* localpart and a matching domain are eligible for
lookup: 'user' lookups, bare domain lookups and "@domain"
- lookups are not performed. This can significantly reduce the
+ lookups are not performed. This can significantly reduce the
query load on the MySQL server.
domain = postfix.org, <a href="DATABASE_README.html#types">hash</a>:/etc/postfix/searchdomains
- It is best not to use SQL to store the domains eligible for SQL
+ It is best not to use SQL to store the domains eligible for SQL
lookups.
This parameter is available with Postfix 2.2 and later.
the input keys are always unqualified.
<b>expansion_limit (default: 0)</b>
- A limit on the total number of result elements returned (as a
+ A limit on the total number of result elements returned (as a
comma separated list) by a lookup against the map. A setting of
- zero disables the limit. Lookups fail with a temporary error if
- the limit is exceeded. Setting the limit to 1 ensures that
+ zero disables the limit. Lookups fail with a temporary error if
+ the limit is exceeded. Setting the limit to 1 ensures that
lookups do not return multiple values.
<b>option_file</b>
- Read options from the given file instead of the default my.cnf
- location. This reads options from the <b>[client]</b> option group,
+ Read options from the given file instead of the default my.cnf
+ location. This reads options from the <b>[client]</b> option group,
optionally followed by options from the group given with
<b>option_group</b>.
This parameter is available with Postfix 2.11 and later.
<b>option_group (default: Postfix</b> ><b>=3.2: client,</b> <<b>= 3.1: empty)</b>
- Read options from the given group of the mysql options file,
+ Read options from the given group of the mysql options file,
after reading options from the <b>[client]</b> group.
- Postfix 3.2 and later read <b>[client]</b> option group settings by
- default. To disable this specify no <b>option_file</b> and specify
+ Postfix 3.2 and later read <b>[client]</b> option group settings by
+ default. To disable this specify no <b>option_file</b> and specify
"<b>option_group =</b>" (i.e. an empty value).
- Postfix 3.1 and earlier don't read <b>[client]</b> option group set-
- tings unless a non-empty <b>option_file</b> or <b>option_group</b> value are
+ Postfix 3.1 and earlier don't read <b>[client]</b> option group set-
+ tings unless a non-empty <b>option_file</b> or <b>option_group</b> value are
specified. To enable this, specify, for example, "<b>option_group =</b>
<b>client</b>".
This parameter is available with Postfix 2.11 and later.
<b>require_result_set (default: yes)</b>
- If "<b>yes</b>", require that every query returns a result set. If
+ If "<b>yes</b>", require that every query returns a result set. If
"<b>no</b>", treat the absence of a result set as "not found".
This parameter is available with Postfix 3.2 and later.
This parameter is available with Postfix 2.11 and later.
<b>tls_key_file</b>
- File containing the private key corresponding to <b>tls_cert_file</b>.
+ File containing the private key corresponding to <b>tls_cert_file</b>.
This parameter is available with Postfix 2.11 and later.
<b>tls_CAfile</b>
- File containing certificates for all of the X509 Certification
- Authorities the client will recognize. Takes precedence over
+ File containing certificates for all of the X509 Certification
+ Authorities the client will recognize. Takes precedence over
<b>tls_CApath</b>.
This parameter is available with Postfix 2.11 and later.
<b>tls_CApath</b>
- Directory containing X509 Certification Authority certificates
+ Directory containing X509 Certification Authority certificates
in separate individual files.
This parameter is available with Postfix 2.11 and later.
<b>tls_verify_cert (default: no)</b>
- Verify that the server's name matches the common name in the
+ Verify that the server's name matches the common name in the
certificate.
This parameter is available with Postfix 2.11 and later.
<b>USING MYSQL STORED PROCEDURES</b>
- Postfix 3.2 and later support calling a stored procedure instead of
+ Postfix 3.2 and later support calling a stored procedure instead of
using a SELECT statement in the query, e.g.
<b>query</b> = CALL lookup('%s')
The previously described '%' expansions can be used in the parameter(s)
to the stored procedure.
- By default, every stored procedure call must return a result set, i.e.
- every code path must execute a SELECT statement that returns a result
+ By default, every stored procedure call must return a result set, i.e.
+ every code path must execute a SELECT statement that returns a result
set (instead of storing its results in a table). With
- "<b>require_result_set = no</b>", the absence of a result set is treated as
+ "<b>require_result_set = no</b>", the absence of a result set is treated as
"not found".
- A stored procedure must not return multiple result sets. That is,
- there must be no code path that executes multiple SELECT statements
+ A stored procedure must not return multiple result sets. That is,
+ there must be no code path that executes multiple SELECT statements
that return a result (instead of storing their results in a table).
- The following is an example of a stored procedure returning a single
+ The following is an example of a stored procedure returning a single
result set:
CREATE [DEFINER=`user`@`host`] PROCEDURE
select goto from alias where address=param;
END
+<b>OBSOLETE MAIN.CF PARAMETERS</b>
+ For compatibility with other Postfix lookup tables, MySQL parameters
+ can also be defined in <a href="postconf.5.html">main.cf</a>. In order to do that, specify as MySQL
+ source a name that doesn't begin with a slash or a dot. The MySQL
+ parameters will then be accessible as the name you've given the source
+ in its definition, an underscore, and the name of the parameter. For
+ example, if the map is specified as "<a href="mysql_table.5.html">mysql</a>:<i>mysqlname</i>", the parameter
+ "hosts" would be defined in <a href="postconf.5.html">main.cf</a> as "<i>mysqlname</i>_hosts".
+
+ Note: with this form, the passwords for the MySQL sources are written
+ in <a href="postconf.5.html">main.cf</a>, which is normally world-readable. Support for this form
+ will be removed in a future Postfix version.
+
<b>OBSOLETE QUERY INTERFACE</b>
- This section describes an interface that is deprecated as of Postfix
- 2.2. It is replaced by the more general <b>query</b> interface described
- above. If the <b>query</b> parameter is defined, the legacy parameters
- described here ignored. Please migrate to the new interface as the
+ This section describes an interface that is deprecated as of Postfix
+ 2.2. It is replaced by the more general <b>query</b> interface described
+ above. If the <b>query</b> parameter is defined, the legacy parameters
+ described here ignored. Please migrate to the new interface as the
legacy interface may be removed in a future release.
- The following parameters can be used to fill in a SELECT template
+ The following parameters can be used to fill in a SELECT template
statement of the form:
SELECT [<b>select_field</b>]
[<b>additional_conditions</b>]
The specifier %s is replaced by the search string, and is escaped so if
- it contains single quotes or other odd characters, it will not cause a
+ it contains single quotes or other odd characters, it will not cause a
parse error, or worse, a security problem.
<b>select_field</b>
The file /etc/postfix/pgsql-aliases.cf has the same format as the Post-
fix <a href="postconf.5.html">main.cf</a> file, and can specify the parameters described below.
-<b>BACKWARDS COMPATIBILITY</b>
- For compatibility with other Postfix lookup tables, PostgreSQL parame-
- ters can also be defined in <a href="postconf.5.html">main.cf</a>. In order to do that, specify as
- PostgreSQL source a name that doesn't begin with a slash or a dot. The
- PostgreSQL parameters will then be accessible as the name you've given
- the source in its definition, an underscore, and the name of the param-
- eter. For example, if the map is specified as "<a href="pgsql_table.5.html">pgsql</a>:<i>pgsqlname</i>", the
- parameter "hosts" below would be defined in <a href="postconf.5.html">main.cf</a> as "<i>pgsql-</i>
- <i>name</i>_hosts".
-
- Note: with this form, the passwords for the PostgreSQL sources are
- written in <a href="postconf.5.html">main.cf</a>, which is normally world-readable. Support for this
- form will be removed in a future Postfix version.
-
- Normally, the SQL query is specified via a single <b>query</b> parameter
- (described in more detail below). When this parameter is not specified
- in the map definition, Postfix reverts to an older interface, with the
- SQL query constructed from the <b>select_function</b>, <b>select_field</b>, <b>table</b>,
- <b>where_field</b> and <b>additional_conditions</b> parameters. The old interface
- will be gradually phased out. To migrate to the new interface set:
-
- <b>query</b> = SELECT <i>select</i><b>_</b><i>function</i>('%s')
-
- or in the absence of <b>select_function</b>, the lower precedence:
-
- <b>query</b> = SELECT <i>select</i><b>_</b><i>field</i>
- FROM <i>table</i>
- WHERE <i>where</i><b>_</b><i>field</i> = '%s'
- <i>additional</i><b>_</b><i>conditions</i>
-
- Use the value, not the name, of each legacy parameter. Note that the
- <b>additional_conditions</b> parameter is optional and if not empty, will
- always start with <b>AND</b>.
-
<b>LIST MEMBERSHIP</b>
When using SQL to store lists such as $<a href="postconf.5.html#mynetworks">mynetworks</a>, $<a href="postconf.5.html#mydestination">mydestination</a>,
$<a href="postconf.5.html#relay_domains">relay_domains</a>, $<a href="postconf.5.html#local_recipient_maps">local_recipient_maps</a>, etc., it is important to under-
the limit is exceeded. Setting the limit to 1 ensures that
lookups do not return multiple values.
+<b>OBSOLETE MAIN.CF PARAMETERS</b>
+ For compatibility with other Postfix lookup tables, PostgreSQL parame-
+ ters can also be defined in <a href="postconf.5.html">main.cf</a>. In order to do that, specify as
+ PostgreSQL source a name that doesn't begin with a slash or a dot. The
+ PostgreSQL parameters will then be accessible as the name you've given
+ the source in its definition, an underscore, and the name of the param-
+ eter. For example, if the map is specified as "<a href="pgsql_table.5.html">pgsql</a>:<i>pgsqlname</i>", the
+ parameter "hosts" would be defined in <a href="postconf.5.html">main.cf</a> as "<i>pgsqlname</i>_hosts".
+
+ Note: with this form, the passwords for the PostgreSQL sources are
+ written in <a href="postconf.5.html">main.cf</a>, which is normally world-readable. Support for this
+ form will be removed in a future Postfix version.
+
<b>OBSOLETE QUERY INTERFACES</b>
This section describes query interfaces that are deprecated as of Post-
fix 2.2. Please migrate to the new <b>query</b> interface as the old inter-
The file /etc/postfix/sqlite-aliases.cf has the same format as the
Postfix <a href="postconf.5.html">main.cf</a> file, and can specify the parameters described below.
-<b>BACKWARDS COMPATIBILITY</b>
- For compatibility with other Postfix lookup tables, SQLite parameters
- can also be defined in <a href="postconf.5.html">main.cf</a>. In order to do that, specify as SQLite
- source a name that doesn't begin with a slash or a dot. The SQLite
- parameters will then be accessible as the name you've given the source
- in its definition, an underscore, and the name of the parameter. For
- example, if the map is specified as "<a href="sqlite_table.5.html">sqlite</a>:<i>sqlitename</i>", the parameter
- "query" below would be defined in <a href="postconf.5.html">main.cf</a> as "<i>sqlitename</i>_query".
-
- Normally, the SQL query is specified via a single <b>query</b> parameter
- (described in more detail below). When this parameter is not specified
- in the map definition, Postfix reverts to an older interface, with the
- SQL query constructed from the <b>select_field</b>, <b>table</b>, <b>where_field</b> and
- <b>additional_conditions</b> parameters. The old interface will be gradually
- phased out. To migrate to the new interface set:
-
- <b>query</b> = SELECT [<i>select</i><b>_</b><i>field</i>]
- FROM [<i>table</i>]
- WHERE [<i>where</i><b>_</b><i>field</i>] = '%s'
- [<i>additional</i><b>_</b><i>conditions</i>]
-
- Insert the value, not the name, of each legacy parameter. Note that the
- <b>additional_conditions</b> parameter is optional and if not empty, will
- always start with <b>AND</b>.
-
<b>LIST MEMBERSHIP</b>
- When using SQL to store lists such as $<a href="postconf.5.html#mynetworks">mynetworks</a>, $<a href="postconf.5.html#mydestination">mydestination</a>,
- $<a href="postconf.5.html#relay_domains">relay_domains</a>, $<a href="postconf.5.html#local_recipient_maps">local_recipient_maps</a>, etc., it is important to under-
+ When using SQL to store lists such as $<a href="postconf.5.html#mynetworks">mynetworks</a>, $<a href="postconf.5.html#mydestination">mydestination</a>,
+ $<a href="postconf.5.html#relay_domains">relay_domains</a>, $<a href="postconf.5.html#local_recipient_maps">local_recipient_maps</a>, etc., it is important to under-
stand that the table must store each list member as a separate key. The
- table lookup verifies the *existence* of the key. See "Postfix lists
+ table lookup verifies the *existence* of the key. See "Postfix lists
versus tables" in the <a href="DATABASE_README.html">DATABASE_README</a> document for a discussion.
- Do NOT create tables that return the full list of domains in $<a href="postconf.5.html#mydestination">mydesti</a>-
+ Do NOT create tables that return the full list of domains in $<a href="postconf.5.html#mydestination">mydesti</a>-
<a href="postconf.5.html#mydestination">nation</a> or $<a href="postconf.5.html#relay_domains">relay_domains</a> etc., or IP addresses in $<a href="postconf.5.html#mynetworks">mynetworks</a>.
DO create tables with each matching item as a key and with an arbitrary
- value. With SQL databases it is not uncommon to return the key itself
+ value. With SQL databases it is not uncommon to return the key itself
or a constant value.
<b>SQLITE PARAMETERS</b>
<b>dbpath</b> The SQLite database file location. Example:
dbpath = customer_database
- <b>query</b> The SQL query template used to search the database, where <b>%s</b> is
- a substitute for the address Postfix is trying to resolve, e.g.
+ <b>query</b> The SQL query template used to search the database, where <b>%s</b> is
+ a substitute for the address Postfix is trying to resolve, e.g.
query = SELECT replacement FROM aliases WHERE mailbox = '%s'
This parameter supports the following '%' expansions:
<b>%%</b> This is replaced by a literal '%' character.
- <b>%s</b> This is replaced by the input key. SQL quoting is used
- to make sure that the input key does not add unexpected
+ <b>%s</b> This is replaced by the input key. SQL quoting is used
+ to make sure that the input key does not add unexpected
metacharacters.
<b>%u</b> When the input key is an address of the form user@domain,
- <b>%u</b> is replaced by the SQL quoted local part of the
- address. Otherwise, <b>%u</b> is replaced by the entire search
- string. If the localpart is empty, the query is sup-
+ <b>%u</b> is replaced by the SQL quoted local part of the
+ address. Otherwise, <b>%u</b> is replaced by the entire search
+ string. If the localpart is empty, the query is sup-
pressed and returns no results.
<b>%d</b> When the input key is an address of the form user@domain,
- <b>%d</b> is replaced by the SQL quoted domain part of the
- address. Otherwise, the query is suppressed and returns
+ <b>%d</b> is replaced by the SQL quoted domain part of the
+ address. Otherwise, the query is suppressed and returns
no results.
<b>%[SUD]</b> The upper-case equivalents of the above expansions behave
- in the <b>query</b> parameter identically to their lower-case
- counter-parts. With the <b>result_format</b> parameter (see
- below), they expand the input key rather than the result
+ in the <b>query</b> parameter identically to their lower-case
+ counter-parts. With the <b>result_format</b> parameter (see
+ below), they expand the input key rather than the result
value.
- <b>%[1-9]</b> The patterns %1, %2, ... %9 are replaced by the corre-
- sponding most significant component of the input key's
- domain. If the input key is <i>user@mail.example.com</i>, then
+ <b>%[1-9]</b> The patterns %1, %2, ... %9 are replaced by the corre-
+ sponding most significant component of the input key's
+ domain. If the input key is <i>user@mail.example.com</i>, then
%1 is <b>com</b>, %2 is <b>example</b> and %3 is <b>mail</b>. If the input key
- is unqualified or does not have enough domain components
- to satisfy all the specified patterns, the query is sup-
+ is unqualified or does not have enough domain components
+ to satisfy all the specified patterns, the query is sup-
pressed and returns no results.
- The <b>domain</b> parameter described below limits the input keys to
- addresses in matching domains. When the <b>domain</b> parameter is
+ The <b>domain</b> parameter described below limits the input keys to
+ addresses in matching domains. When the <b>domain</b> parameter is
non-empty, SQL queries for unqualified addresses or addresses in
non-matching domains are suppressed and return no results.
- This parameter is available with Postfix 2.2. In prior releases
- the SQL query was built from the separate parameters:
- <b>select_field</b>, <b>table</b>, <b>where_field</b> and <b>additional_conditions</b>. The
+ This parameter is available with Postfix 2.2. In prior releases
+ the SQL query was built from the separate parameters:
+ <b>select_field</b>, <b>table</b>, <b>where_field</b> and <b>additional_conditions</b>. The
mapping from the old parameters to the equivalent query is:
SELECT [<b>select_field</b>]
WHERE [<b>where_field</b>] = '%s'
[<b>additional_conditions</b>]
- The '%s' in the <b>WHERE</b> clause expands to the escaped search
- string. With Postfix 2.2 these legacy parameters are used if
+ The '%s' in the <b>WHERE</b> clause expands to the escaped search
+ string. With Postfix 2.2 these legacy parameters are used if
the <b>query</b> parameter is not specified.
NOTE: DO NOT put quotes around the query parameter.
<b>result_format (default: %s</b>)
Format template applied to result attributes. Most commonly used
- to append (or prepend) text to the result. This parameter sup-
+ to append (or prepend) text to the result. This parameter sup-
ports the following '%' expansions:
<b>%%</b> This is replaced by a literal '%' character.
- <b>%s</b> This is replaced by the value of the result attribute.
+ <b>%s</b> This is replaced by the value of the result attribute.
When result is empty it is skipped.
<b>%u</b> When the result attribute value is an address of the form
- user@domain, <b>%u</b> is replaced by the local part of the
- address. When the result has an empty localpart it is
+ user@domain, <b>%u</b> is replaced by the local part of the
+ address. When the result has an empty localpart it is
skipped.
- <b>%d</b> When a result attribute value is an address of the form
- user@domain, <b>%d</b> is replaced by the domain part of the
- attribute value. When the result is unqualified it is
+ <b>%d</b> When a result attribute value is an address of the form
+ user@domain, <b>%d</b> is replaced by the domain part of the
+ attribute value. When the result is unqualified it is
skipped.
<b>%[SUD1-9]</b>
- The upper-case and decimal digit expansions interpolate
- the parts of the input key rather than the result. Their
- behavior is identical to that described with <b>query</b>, and
- in fact because the input key is known in advance,
- queries whose key does not contain all the information
- specified in the result template are suppressed and
+ The upper-case and decimal digit expansions interpolate
+ the parts of the input key rather than the result. Their
+ behavior is identical to that described with <b>query</b>, and
+ in fact because the input key is known in advance,
+ queries whose key does not contain all the information
+ specified in the result template are suppressed and
return no results.
For example, using "result_format = <a href="smtp.8.html">smtp</a>:[%s]" allows one to use
a mailHost attribute as the basis of a <a href="transport.5.html">transport(5)</a> table. After
- applying the result format, multiple values are concatenated as
+ applying the result format, multiple values are concatenated as
comma separated strings. The expansion_limit and parameter
- explained below allows one to restrict the number of values in
+ explained below allows one to restrict the number of values in
the result, which is especially useful for maps that must return
at most one value.
- The default value <b>%s</b> specifies that each result value should be
+ The default value <b>%s</b> specifies that each result value should be
used as is.
This parameter is available with Postfix 2.2 and later.
<b>domain (default: no domain list)</b>
This is a list of domain names, paths to files, or dictionaries.
- When specified, only fully qualified search keys with a
- *non-empty* localpart and a matching domain are eligible for
+ When specified, only fully qualified search keys with a
+ *non-empty* localpart and a matching domain are eligible for
lookup: 'user' lookups, bare domain lookups and "@domain"
- lookups are not performed. This can significantly reduce the
+ lookups are not performed. This can significantly reduce the
query load on the SQLite server.
domain = postfix.org, <a href="DATABASE_README.html#types">hash</a>:/etc/postfix/searchdomains
- It is best not to use SQL to store the domains eligible for SQL
+ It is best not to use SQL to store the domains eligible for SQL
lookups.
This parameter is available with Postfix 2.2 and later.
the input keys are always unqualified.
<b>expansion_limit (default: 0)</b>
- A limit on the total number of result elements returned (as a
+ A limit on the total number of result elements returned (as a
comma separated list) by a lookup against the map. A setting of
- zero disables the limit. Lookups fail with a temporary error if
- the limit is exceeded. Setting the limit to 1 ensures that
+ zero disables the limit. Lookups fail with a temporary error if
+ the limit is exceeded. Setting the limit to 1 ensures that
lookups do not return multiple values.
+<b>OBSOLETE MAIN.CF PARAMETERS</b>
+ For compatibility with other Postfix lookup tables, SQLite parameters
+ can also be defined in <a href="postconf.5.html">main.cf</a>. In order to do that, specify as SQLite
+ source a name that doesn't begin with a slash or a dot. The SQLite
+ parameters will then be accessible as the name you've given the source
+ in its definition, an underscore, and the name of the parameter. For
+ example, if the map is specified as "<a href="sqlite_table.5.html">sqlite</a>:<i>sqlitename</i>", the parameter
+ "query" would be defined in <a href="postconf.5.html">main.cf</a> as "<i>sqlitename</i>_query".
+
<b>OBSOLETE QUERY INTERFACE</b>
- This section describes an interface that is deprecated as of Postfix
- 2.2. It is replaced by the more general <b>query</b> interface described
- above. If the <b>query</b> parameter is defined, the legacy parameters
- described here ignored. Please migrate to the new interface as the
+ This section describes an interface that is deprecated as of Postfix
+ 2.2. It is replaced by the more general <b>query</b> interface described
+ above. If the <b>query</b> parameter is defined, the legacy parameters
+ described here ignored. Please migrate to the new interface as the
legacy interface may be removed in a future release.
- The following parameters can be used to fill in a SELECT template
+ The following parameters can be used to fill in a SELECT template
statement of the form:
SELECT [<b>select_field</b>]
[<b>additional_conditions</b>]
The specifier %s is replaced by the search string, and is escaped so if
- it contains single quotes or other odd characters, it will not cause a
+ it contains single quotes or other odd characters, it will not cause a
parse error, or worse, a security problem.
<b>select_field</b>
described below. An example is given at the end of this manual.
This configuration method is available with Postfix version
-2.1 and later. See the section "BACKWARDS COMPATIBILITY"
+2.1 and later. See the section "OBSOLETE MAIN.CF PARAMETERS"
below for older Postfix versions.
For details about LDAP SSL and STARTTLS, see the section
on SSL and STARTTLS below.
-.SH "BACKWARDS COMPATIBILITY"
-.na
-.nf
-.ad
-.fi
-For backwards compatibility with Postfix version 2.0 and earlier,
-LDAP parameters can also be defined in main.cf. Specify
-as LDAP source a name that doesn't begin with a slash or
-a dot. The LDAP parameters will then be accessible as the
-name you've given the source in its definition, an underscore,
-and the name of the parameter. For example, if the map is
-specified as "ldap:\fIldapsource\fR", the "server_host"
-parameter below would be defined in main.cf as
-"\fIldapsource\fR_server_host".
-
-Note: with this form, the passwords for the LDAP sources are
-written in main.cf, which is normally world\-readable. Support
-for this form will be removed in a future Postfix version.
-
-For backwards compatibility with the pre
-2.2 LDAP clients, \fBresult_filter\fR can for now be used instead
-of \fBresult_format\fR, when the latter parameter is not also set.
-The new name better reflects the function of the parameter. This
-compatibility interface may be removed in a future release.
.SH "LIST MEMBERSHIP"
.na
.nf
the "maildrop" attributes of those found, and build a list
of their maildrops, which will be treated as RFC822 addresses
to which the message will be delivered.
+.SH "OBSOLETE MAIN.CF PARAMETERS"
+.na
+.nf
+.ad
+.fi
+For backwards compatibility with Postfix version 2.0 and earlier,
+LDAP parameters can also be defined in main.cf. Specify
+as LDAP source a name that doesn't begin with a slash or
+a dot. The LDAP parameters will then be accessible as the
+name you've given the source in its definition, an underscore,
+and the name of the parameter. For example, if the map is
+specified as "ldap:\fIldapsource\fR", the "server_host"
+parameter below would be defined in main.cf as
+"\fIldapsource\fR_server_host".
+
+Note: with this form, the passwords for the LDAP sources are
+written in main.cf, which is normally world\-readable. Support
+for this form will be removed in a future Postfix version.
+.SH "OTHER OBSOLETE FEATURES"
+.na
+.nf
+.ad
+.fi
+For backwards compatibility with the pre
+2.2 LDAP clients, \fBresult_filter\fR can for now be used instead
+of \fBresult_format\fR, when the latter parameter is not also set.
+The new name better reflects the function of the parameter. This
+compatibility interface may be removed in a future release.
.SH "SEE ALSO"
.na
.nf
The file /etc/postfix/mysql\-aliases.cf has the same format as
the Postfix main.cf file, and can specify the parameters
described below.
-.SH "BACKWARDS COMPATIBILITY"
-.na
-.nf
-.ad
-.fi
-For compatibility with other Postfix lookup tables, MySQL
-parameters can also be defined in main.cf. In order to do that,
-specify as MySQL source a name that doesn't begin with a slash
-or a dot. The MySQL parameters will then be accessible as the
-name you've given the source in its definition, an underscore,
-and the name of the parameter. For example, if the map is
-specified as "mysql:\fImysqlname\fR", the parameter "hosts"
-below would be defined in main.cf as "\fImysqlname\fR_hosts".
-
-Note: with this form, the passwords for the MySQL sources are
-written in main.cf, which is normally world\-readable. Support
-for this form will be removed in a future Postfix version.
-
-Normally, the SQL query is specified via a single \fBquery\fR
-parameter (described in more detail below). When this
-parameter is not specified in the map definition, Postfix
-reverts to an older interface, with the SQL query constructed
-from the \fBselect_field\fR, \fBtable\fR, \fBwhere_field\fR
-and \fBadditional_conditions\fR parameters. The old interface
-will be gradually phased out. To migrate to the new interface
-set:
-
-.nf
- \fBquery\fR = SELECT [\fIselect_field\fR]
- FROM [\fItable\fR]
- WHERE [\fIwhere_field\fR] = '%s'
- [\fIadditional_conditions\fR]
-.fi
-
-Insert the value, not the name, of each legacy parameter. Note
-that the \fBadditional_conditions\fR parameter is optional
-and if not empty, will always start with \fBAND\fR.
.SH "LIST MEMBERSHIP"
.na
.nf
select goto from alias where address=param;
END
.fi
+.SH "OBSOLETE MAIN.CF PARAMETERS"
+.na
+.nf
+.ad
+.fi
+For compatibility with other Postfix lookup tables, MySQL
+parameters can also be defined in main.cf. In order to do that,
+specify as MySQL source a name that doesn't begin with a slash
+or a dot. The MySQL parameters will then be accessible as the
+name you've given the source in its definition, an underscore,
+and the name of the parameter. For example, if the map is
+specified as "mysql:\fImysqlname\fR", the parameter "hosts"
+would be defined in main.cf as "\fImysqlname\fR_hosts".
+
+Note: with this form, the passwords for the MySQL sources are
+written in main.cf, which is normally world\-readable. Support
+for this form will be removed in a future Postfix version.
.SH "OBSOLETE QUERY INTERFACE"
.na
.nf
The file /etc/postfix/pgsql\-aliases.cf has the same format as
the Postfix main.cf file, and can specify the parameters
described below.
-.SH "BACKWARDS COMPATIBILITY"
-.na
-.nf
-.ad
-.fi
-For compatibility with other Postfix lookup tables, PostgreSQL
-parameters can also be defined in main.cf. In order to do
-that, specify as PostgreSQL source a name that doesn't begin
-with a slash or a dot. The PostgreSQL parameters will then
-be accessible as the name you've given the source in its
-definition, an underscore, and the name of the parameter. For
-example, if the map is specified as "pgsql:\fIpgsqlname\fR",
-the parameter "hosts" below would be defined in main.cf as
-"\fIpgsqlname\fR_hosts".
-
-Note: with this form, the passwords for the PostgreSQL sources
-are written in main.cf, which is normally world\-readable.
-Support for this form will be removed in a future Postfix
-version.
-
-Normally, the SQL query is specified via a single \fBquery\fR
-parameter (described in more detail below). When this
-parameter is not specified in the map definition, Postfix
-reverts to an older interface, with the SQL query
-constructed from the \fBselect_function\fR, \fBselect_field\fR,
-\fBtable\fR, \fBwhere_field\fR and \fBadditional_conditions\fR
-parameters. The old interface will be gradually phased
-out. To migrate to the new interface set:
-
-.nf
- \fBquery\fR = SELECT \fIselect_function\fR('%s')
-.fi
-
-or in the absence of \fBselect_function\fR, the lower precedence:
-
-.nf
- \fBquery\fR = SELECT \fIselect_field\fR
- FROM \fItable\fR
- WHERE \fIwhere_field\fR = '%s'
- \fIadditional_conditions\fR
-.fi
-
-Use the value, not the name, of each legacy parameter. Note
-that the \fBadditional_conditions\fR parameter is optional
-and if not empty, will always start with \fBAND\fR.
.SH "LIST MEMBERSHIP"
.na
.nf
temporary error if the limit is exceeded. Setting the
limit to 1 ensures that lookups do not return multiple
values.
+.SH "OBSOLETE MAIN.CF PARAMETERS"
+.na
+.nf
+.ad
+.fi
+For compatibility with other Postfix lookup tables, PostgreSQL
+parameters can also be defined in main.cf. In order to do
+that, specify as PostgreSQL source a name that doesn't begin
+with a slash or a dot. The PostgreSQL parameters will then
+be accessible as the name you've given the source in its
+definition, an underscore, and the name of the parameter. For
+example, if the map is specified as "pgsql:\fIpgsqlname\fR",
+the parameter "hosts" would be defined in main.cf as
+"\fIpgsqlname\fR_hosts".
+
+Note: with this form, the passwords for the PostgreSQL sources
+are written in main.cf, which is normally world\-readable.
+Support for this form will be removed in a future Postfix
+version.
.SH "OBSOLETE QUERY INTERFACES"
.na
.nf
The file /etc/postfix/sqlite\-aliases.cf has the same format as
the Postfix main.cf file, and can specify the parameters
described below.
-.SH "BACKWARDS COMPATIBILITY"
-.na
-.nf
-.ad
-.fi
-For compatibility with other Postfix lookup tables, SQLite
-parameters can also be defined in main.cf. In order to do that,
-specify as SQLite source a name that doesn't begin with a slash
-or a dot. The SQLite parameters will then be accessible as the
-name you've given the source in its definition, an underscore,
-and the name of the parameter. For example, if the map is
-specified as "sqlite:\fIsqlitename\fR", the parameter "query"
-below would be defined in main.cf as "\fIsqlitename\fR_query".
-
-Normally, the SQL query is specified via a single \fBquery\fR
-parameter (described in more detail below). When this
-parameter is not specified in the map definition, Postfix
-reverts to an older interface, with the SQL query constructed
-from the \fBselect_field\fR, \fBtable\fR, \fBwhere_field\fR
-and \fBadditional_conditions\fR parameters. The old interface
-will be gradually phased out. To migrate to the new interface
-set:
-
-.nf
- \fBquery\fR = SELECT [\fIselect_field\fR]
- FROM [\fItable\fR]
- WHERE [\fIwhere_field\fR] = '%s'
- [\fIadditional_conditions\fR]
-.fi
-
-Insert the value, not the name, of each legacy parameter. Note
-that the \fBadditional_conditions\fR parameter is optional
-and if not empty, will always start with \fBAND\fR.
.SH "LIST MEMBERSHIP"
.na
.nf
temporary error if the limit is exceeded. Setting the
limit to 1 ensures that lookups do not return multiple
values.
+.SH "OBSOLETE MAIN.CF PARAMETERS"
+.na
+.nf
+.ad
+.fi
+For compatibility with other Postfix lookup tables, SQLite
+parameters can also be defined in main.cf. In order to do that,
+specify as SQLite source a name that doesn't begin with a slash
+or a dot. The SQLite parameters will then be accessible as the
+name you've given the source in its definition, an underscore,
+and the name of the parameter. For example, if the map is
+specified as "sqlite:\fIsqlitename\fR", the parameter "query"
+would be defined in main.cf as "\fIsqlitename\fR_query".
.SH "OBSOLETE QUERY INTERFACE"
.na
.nf
# described below. An example is given at the end of this manual.
#
# This configuration method is available with Postfix version
-# 2.1 and later. See the section "BACKWARDS COMPATIBILITY"
+# 2.1 and later. See the section "OBSOLETE MAIN.CF PARAMETERS"
# below for older Postfix versions.
#
# For details about LDAP SSL and STARTTLS, see the section
# on SSL and STARTTLS below.
-# BACKWARDS COMPATIBILITY
-# .ad
-# .fi
-# For backwards compatibility with Postfix version 2.0 and earlier,
-# LDAP parameters can also be defined in main.cf. Specify
-# as LDAP source a name that doesn't begin with a slash or
-# a dot. The LDAP parameters will then be accessible as the
-# name you've given the source in its definition, an underscore,
-# and the name of the parameter. For example, if the map is
-# specified as "ldap:\fIldapsource\fR", the "server_host"
-# parameter below would be defined in main.cf as
-# "\fIldapsource\fR_server_host".
-#
-# Note: with this form, the passwords for the LDAP sources are
-# written in main.cf, which is normally world-readable. Support
-# for this form will be removed in a future Postfix version.
-#
-# For backwards compatibility with the pre
-# 2.2 LDAP clients, \fBresult_filter\fR can for now be used instead
-# of \fBresult_format\fR, when the latter parameter is not also set.
-# The new name better reflects the function of the parameter. This
-# compatibility interface may be removed in a future release.
# LIST MEMBERSHIP
# .ad
# .fi
# the "maildrop" attributes of those found, and build a list
# of their maildrops, which will be treated as RFC822 addresses
# to which the message will be delivered.
+# OBSOLETE MAIN.CF PARAMETERS
+# .ad
+# .fi
+# For backwards compatibility with Postfix version 2.0 and earlier,
+# LDAP parameters can also be defined in main.cf. Specify
+# as LDAP source a name that doesn't begin with a slash or
+# a dot. The LDAP parameters will then be accessible as the
+# name you've given the source in its definition, an underscore,
+# and the name of the parameter. For example, if the map is
+# specified as "ldap:\fIldapsource\fR", the "server_host"
+# parameter below would be defined in main.cf as
+# "\fIldapsource\fR_server_host".
+#
+# Note: with this form, the passwords for the LDAP sources are
+# written in main.cf, which is normally world-readable. Support
+# for this form will be removed in a future Postfix version.
+# OTHER OBSOLETE FEATURES
+# .ad
+# .fi
+# For backwards compatibility with the pre
+# 2.2 LDAP clients, \fBresult_filter\fR can for now be used instead
+# of \fBresult_format\fR, when the latter parameter is not also set.
+# The new name better reflects the function of the parameter. This
+# compatibility interface may be removed in a future release.
# SEE ALSO
# postmap(1), Postfix lookup table manager
# postconf(5), configuration parameters
# The file /etc/postfix/mysql-aliases.cf has the same format as
# the Postfix main.cf file, and can specify the parameters
# described below.
-# BACKWARDS COMPATIBILITY
-# .ad
-# .fi
-# For compatibility with other Postfix lookup tables, MySQL
-# parameters can also be defined in main.cf. In order to do that,
-# specify as MySQL source a name that doesn't begin with a slash
-# or a dot. The MySQL parameters will then be accessible as the
-# name you've given the source in its definition, an underscore,
-# and the name of the parameter. For example, if the map is
-# specified as "mysql:\fImysqlname\fR", the parameter "hosts"
-# below would be defined in main.cf as "\fImysqlname\fR_hosts".
-#
-# Note: with this form, the passwords for the MySQL sources are
-# written in main.cf, which is normally world-readable. Support
-# for this form will be removed in a future Postfix version.
-#
-# Normally, the SQL query is specified via a single \fBquery\fR
-# parameter (described in more detail below). When this
-# parameter is not specified in the map definition, Postfix
-# reverts to an older interface, with the SQL query constructed
-# from the \fBselect_field\fR, \fBtable\fR, \fBwhere_field\fR
-# and \fBadditional_conditions\fR parameters. The old interface
-# will be gradually phased out. To migrate to the new interface
-# set:
-#
-# .nf
-# \fBquery\fR = SELECT [\fIselect_field\fR]
-# FROM [\fItable\fR]
-# WHERE [\fIwhere_field\fR] = '%s'
-# [\fIadditional_conditions\fR]
-# .fi
-#
-# Insert the value, not the name, of each legacy parameter. Note
-# that the \fBadditional_conditions\fR parameter is optional
-# and if not empty, will always start with \fBAND\fR.
# LIST MEMBERSHIP
# .ad
# .fi
# select goto from alias where address=param;
# END
# .fi
+# OBSOLETE MAIN.CF PARAMETERS
+# .ad
+# .fi
+# For compatibility with other Postfix lookup tables, MySQL
+# parameters can also be defined in main.cf. In order to do that,
+# specify as MySQL source a name that doesn't begin with a slash
+# or a dot. The MySQL parameters will then be accessible as the
+# name you've given the source in its definition, an underscore,
+# and the name of the parameter. For example, if the map is
+# specified as "mysql:\fImysqlname\fR", the parameter "hosts"
+# would be defined in main.cf as "\fImysqlname\fR_hosts".
+#
+# Note: with this form, the passwords for the MySQL sources are
+# written in main.cf, which is normally world-readable. Support
+# for this form will be removed in a future Postfix version.
# OBSOLETE QUERY INTERFACE
# .ad
# .fi
# The file /etc/postfix/pgsql-aliases.cf has the same format as
# the Postfix main.cf file, and can specify the parameters
# described below.
-# BACKWARDS COMPATIBILITY
-# .ad
-# .fi
-# For compatibility with other Postfix lookup tables, PostgreSQL
-# parameters can also be defined in main.cf. In order to do
-# that, specify as PostgreSQL source a name that doesn't begin
-# with a slash or a dot. The PostgreSQL parameters will then
-# be accessible as the name you've given the source in its
-# definition, an underscore, and the name of the parameter. For
-# example, if the map is specified as "pgsql:\fIpgsqlname\fR",
-# the parameter "hosts" below would be defined in main.cf as
-# "\fIpgsqlname\fR_hosts".
-#
-# Note: with this form, the passwords for the PostgreSQL sources
-# are written in main.cf, which is normally world-readable.
-# Support for this form will be removed in a future Postfix
-# version.
-#
-# Normally, the SQL query is specified via a single \fBquery\fR
-# parameter (described in more detail below). When this
-# parameter is not specified in the map definition, Postfix
-# reverts to an older interface, with the SQL query
-# constructed from the \fBselect_function\fR, \fBselect_field\fR,
-# \fBtable\fR, \fBwhere_field\fR and \fBadditional_conditions\fR
-# parameters. The old interface will be gradually phased
-# out. To migrate to the new interface set:
-#
-# .nf
-# \fBquery\fR = SELECT \fIselect_function\fR('%s')
-# .fi
-#
-# or in the absence of \fBselect_function\fR, the lower precedence:
-#
-# .nf
-# \fBquery\fR = SELECT \fIselect_field\fR
-# FROM \fItable\fR
-# WHERE \fIwhere_field\fR = '%s'
-# \fIadditional_conditions\fR
-# .fi
-#
-# Use the value, not the name, of each legacy parameter. Note
-# that the \fBadditional_conditions\fR parameter is optional
-# and if not empty, will always start with \fBAND\fR.
# LIST MEMBERSHIP
# .ad
# .fi
# temporary error if the limit is exceeded. Setting the
# limit to 1 ensures that lookups do not return multiple
# values.
+# OBSOLETE MAIN.CF PARAMETERS
+# .ad
+# .fi
+# For compatibility with other Postfix lookup tables, PostgreSQL
+# parameters can also be defined in main.cf. In order to do
+# that, specify as PostgreSQL source a name that doesn't begin
+# with a slash or a dot. The PostgreSQL parameters will then
+# be accessible as the name you've given the source in its
+# definition, an underscore, and the name of the parameter. For
+# example, if the map is specified as "pgsql:\fIpgsqlname\fR",
+# the parameter "hosts" would be defined in main.cf as
+# "\fIpgsqlname\fR_hosts".
+#
+# Note: with this form, the passwords for the PostgreSQL sources
+# are written in main.cf, which is normally world-readable.
+# Support for this form will be removed in a future Postfix
+# version.
# OBSOLETE QUERY INTERFACES
# .ad
# .fi
# The file /etc/postfix/sqlite-aliases.cf has the same format as
# the Postfix main.cf file, and can specify the parameters
# described below.
-# BACKWARDS COMPATIBILITY
-# .ad
-# .fi
-# For compatibility with other Postfix lookup tables, SQLite
-# parameters can also be defined in main.cf. In order to do that,
-# specify as SQLite source a name that doesn't begin with a slash
-# or a dot. The SQLite parameters will then be accessible as the
-# name you've given the source in its definition, an underscore,
-# and the name of the parameter. For example, if the map is
-# specified as "sqlite:\fIsqlitename\fR", the parameter "query"
-# below would be defined in main.cf as "\fIsqlitename\fR_query".
-#
-# Normally, the SQL query is specified via a single \fBquery\fR
-# parameter (described in more detail below). When this
-# parameter is not specified in the map definition, Postfix
-# reverts to an older interface, with the SQL query constructed
-# from the \fBselect_field\fR, \fBtable\fR, \fBwhere_field\fR
-# and \fBadditional_conditions\fR parameters. The old interface
-# will be gradually phased out. To migrate to the new interface
-# set:
-#
-# .nf
-# \fBquery\fR = SELECT [\fIselect_field\fR]
-# FROM [\fItable\fR]
-# WHERE [\fIwhere_field\fR] = '%s'
-# [\fIadditional_conditions\fR]
-# .fi
-#
-# Insert the value, not the name, of each legacy parameter. Note
-# that the \fBadditional_conditions\fR parameter is optional
-# and if not empty, will always start with \fBAND\fR.
# LIST MEMBERSHIP
# .ad
# .fi
# temporary error if the limit is exceeded. Setting the
# limit to 1 ensures that lookups do not return multiple
# values.
+# OBSOLETE MAIN.CF PARAMETERS
+# .ad
+# .fi
+# For compatibility with other Postfix lookup tables, SQLite
+# parameters can also be defined in main.cf. In order to do that,
+# specify as SQLite source a name that doesn't begin with a slash
+# or a dot. The SQLite parameters will then be accessible as the
+# name you've given the source in its definition, an underscore,
+# and the name of the parameter. For example, if the map is
+# specified as "sqlite:\fIsqlitename\fR", the parameter "query"
+# would be defined in main.cf as "\fIsqlitename\fR_query".
# OBSOLETE QUERY INTERFACE
# .ad
# .fi
* Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only.
*/
-#define MAIL_RELEASE_DATE "20161227"
+#define MAIL_RELEASE_DATE "20161231"
#define MAIL_VERSION_NUMBER "3.2"
#ifdef SNAPSHOT
base32_code_test dict_thash_test surrogate_test timecmp_test \
dict_static_test dict_inline_test midna_domain_test casefold_test \
dict_utf8_test strcasecmp_utf8_test vbuf_print_test dict_regexp_test \
- dict_union_test dict_pipe_test
+ dict_union_test dict_pipe_test miss_endif_cidr_test \
+ miss_endif_pcre_test miss_endif_regexp_test
root_tests:
diff dict_cidr.ref dict_cidr.tmp
rm -f dict_cidr.tmp
+miss_endif_cidr_test: dict_open miss_endif_cidr.map miss_endif_cidr.ref
+ echo get 1.2.3.5 | $(SHLIB_ENV) ./dict_open cidr:miss_endif_cidr.map read 2>&1 | sed 's/uid=[0-9][0-9][0-9]*/uid=USER/' >dict_cidr.tmp
+ diff miss_endif_cidr.ref dict_cidr.tmp
+ rm -f dict_cidr.tmp
+
+miss_endif_pcre_test: dict_open miss_endif_re.map miss_endif_pcre.ref
+ echo get 1.2.3.5 | $(SHLIB_ENV) ./dict_open pcre:miss_endif_re.map read 2>&1 | sed 's/uid=[0-9][0-9][0-9]*/uid=USER/' >dict_pcre.tmp
+ diff miss_endif_pcre.ref dict_pcre.tmp
+ rm -f dict_pcre.tmp
+
+miss_endif_regexp_test: dict_open miss_endif_re.map miss_endif_regexp.ref
+ echo get 1.2.3.5 | $(SHLIB_ENV) ./dict_open regexp:miss_endif_re.map read 2>&1 | sed 's/uid=[0-9][0-9][0-9]*/uid=USER/' >dict_regexp.tmp
+ diff miss_endif_regexp.ref dict_regexp.tmp
+ rm -f dict_regexp.tmp
+
dict_seq_test: dict_open testdb dict_seq.in dict_seq.ref
rm -f testdb.db testdb.dir testdb.pag
$(SHLIB_ENV) ./dict_open hash:testdb create sync < dict_seq.in 2>&1 | sed 's/uid=[0-9][0-9][0-9]*/uid=USER/' > dict_seq.tmp
continue;
/* An IF without matching ENDIF has no end-of block entry. */
if ((entry = entry->block_end) == 0)
- break;
+ return (0);
/* FALLTHROUGH */
case CIDR_MATCH_OP_ENDIF:
continue;
/* An IF without matching ENDIF has no "endif" rule. */
if ((rule = if_rule->endif_rule) == 0)
- break;
+ return (0);
/* FALLTHROUGH */
/*
if_rule->match = regexp.match;
if_rule->pattern = engine.pattern;
if_rule->hints = engine.hints;
+ if_rule->endif_rule = 0;
return ((DICT_PCRE_RULE *) if_rule);
}
continue;
/* An IF without matching ENDIF has no "endif" rule. */
if ((rule = if_rule->endif_rule) == 0)
- break;
+ return (0);
/* FALLTHROUGH */
/*
sizeof(DICT_REGEXP_IF_RULE));
if_rule->expr = expr;
if_rule->match = pattern.match;
+ if_rule->endif_rule = 0;
return ((DICT_REGEXP_RULE *) if_rule);
}
--- /dev/null
+if 1.2.3.4
--- /dev/null
+./dict_open: warning: cidr map miss_endif_cidr.map, line 1: IF has no matching ENDIF
+owner=untrusted (uid=USER)
+> get 1.2.3.5
+1.2.3.5: not found
--- /dev/null
+./dict_open: warning: pcre map miss_endif_re.map, line 1: IF has no matching ENDIF
+owner=untrusted (uid=USER)
+> get 1.2.3.5
+1.2.3.5: not found
--- /dev/null
+./dict_open: warning: regexp map miss_endif_re.map, line 1: IF has no matching ENDIF
+owner=untrusted (uid=USER)
+> get 1.2.3.5
+1.2.3.5: not found