223 lines
9.8 KiB
HTML
223 lines
9.8 KiB
HTML
<html> <head> </head> <body> <pre>
|
|
|
|
VIRTUAL(5) VIRTUAL(5)
|
|
|
|
<b>NAME</b>
|
|
virtual - format of Postfix virtual table
|
|
|
|
<b>SYNOPSIS</b>
|
|
<b>postmap</b> <b>/etc/postfix/virtual</b>
|
|
|
|
<b>DESCRIPTION</b>
|
|
The optional <b>virtual</b> table specifies address redirections
|
|
for local and non-local recipients or domains. The redi-
|
|
rections are used by the <a href="cleanup.8.html"><b>cleanup</b>(8)</a> daemon. The redirec-
|
|
tions are recursive.
|
|
|
|
The <b>virtual</b> redirection is applied only to recipient enve-
|
|
lope addresses, and does not affect message headers.
|
|
Think Sendmail rule set <b>S0</b>, if you like. Use <a href="canonical.5.html"><b>canonical</b>(5)</a>
|
|
mapping to rewrite header and envelope addresses in gen-
|
|
eral.
|
|
|
|
Normally, the <b>virtual</b> table is specified as a text file
|
|
that serves as input to the <a href="postmap.1.html"><b>postmap</b>(1)</a> command. The
|
|
result, an indexed file in <b>dbm</b> or <b>db</b> format, is used for
|
|
fast searching by the mail system. Execute the command
|
|
<b>postmap</b> <b>/etc/postfix/virtual</b> in order to rebuild the
|
|
indexed file after changing the 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 expres-
|
|
sions. In that case, the lookups are done in a slightly
|
|
different way as described below.
|
|
|
|
<b>POSTFIX-STYLE</b> <b>VIRTUAL</b> <b>DOMAINS</b>
|
|
With a Postfix-style virtual domain, the virtual domain
|
|
has its own user name space. Local (i.e. non-virtual)
|
|
usernames are not visible in a Postfix-style virtual
|
|
domain. In particular, local <a href="aliases.5.html"><b>aliases</b>(5)</a> and mailing lists
|
|
are not visible as <i>localname@virtual.domain</i>.
|
|
|
|
Use a Sendmail-style virtual domain (see below) if local
|
|
usernames, <a href="aliases.5.html"><b>aliases</b>(5)</a> or mailing lists should be visible
|
|
as <i>localname@virtual.domain</i>.
|
|
|
|
Support for a Postfix-style virtual domain looks like:
|
|
|
|
/etc/postfix/virtual:
|
|
<i>virtual.domain</i> <i>anything</i> (right-hand content does not matter)
|
|
<i>postmaster@virtual.domain</i> <i>postmaster</i>
|
|
<i>user1@virtual.domain</i> <i>address1</i>
|
|
<i>user2@virtual.domain</i> <i>address2,</i> <i>address3</i>
|
|
|
|
The <i>virtual.domain</i> <i>anything</i> entry is required for a Post-
|
|
fix-style virtual domain.
|
|
|
|
Do not list a Postfix-style virtual domain in the <b>main.cf</b>
|
|
<b>mydestination</b> configuration parameter. Such an entry is
|
|
required only for a Sendmail-style virtual domain.
|
|
|
|
With a Postfix-style virtual domain, the Postfix SMTP
|
|
server accepts mail for <i>known-user@virtual.domain</i> and
|
|
rejects mail for <i>unknown-user</i>@<i>virtual.domain</i> as undeliver-
|
|
able.
|
|
|
|
<b>SENDMAIL-STYLE</b> <b>VIRTUAL</b> <b>DOMAINS</b>
|
|
With a Sendmail-style virtual domain, every local (i.e.
|
|
non-virtual) username is visible in the virtual domain. In
|
|
particular, every local alias and mailing list is visible
|
|
as <i>localname@virtual.domain</i>.
|
|
|
|
Use a Postfix-style virtual domain (see above) if local
|
|
usernames, <a href="aliases.5.html"><b>aliases</b>(5)</a> or mailing lists should not be visi-
|
|
ble as <i>localname@virtual.domain</i>.
|
|
|
|
Support for a Sendmail-style virtual domain looks like:
|
|
|
|
/etc/postfix/main.cf:
|
|
mydestination = $myhostname localhost.$mydomain $mydomain
|
|
<i>virtual.domain</i>
|
|
|
|
/etc/postfix/virtual:
|
|
<i>user1@virtual.domain</i> <i>address1</i>
|
|
<i>user2@virtual.domain</i> <i>address2,</i> <i>address3</i>
|
|
|
|
The <b>main.cf</b> <b>mydestination</b> entry is required for a Send-
|
|
mail-style virtual domain.
|
|
|
|
Do not specify a <i>virtual.domain</i> <i>anything</i> virtual map entry
|
|
for a Sendmail-style virtual domain. Such an entry is
|
|
required only with a Postfix-style virtual domain.
|
|
|
|
With a Sendmail-style virtual domain, the Postfix local
|
|
delivery agent delivers mail for an unknown <i>user</i>@<i>vir-</i>
|
|
<i>tual.domain</i> to a local (i.e. non-virtual) user that has
|
|
the same name; if no such recipient exists, the Postfix
|
|
local delivery agent bounces the mail to the sender.
|
|
|
|
<b>TABLE</b> <b>FORMAT</b>
|
|
The format of the virtual table is as follows, mappings
|
|
being tried in the order as listed in this manual page:
|
|
|
|
<i>pattern</i> <i>result</i>
|
|
When <i>pattern</i> matches a mail address, replace it by
|
|
the corresponding <i>result</i>.
|
|
|
|
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 logi-
|
|
cal line.
|
|
|
|
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:
|
|
|
|
<i>user</i>@<i>domain</i> <i>address,</i> <i>address,</i> <i>...</i>
|
|
Mail for <i>user</i>@<i>domain</i> is redirected to <i>address</i>.
|
|
This form has the highest precedence.
|
|
|
|
<i>user</i> <i>address,</i> <i>address,</i> <i>...</i>
|
|
Mail for <i>user</i>@<i>site</i> is redirected to <i>address</i> when
|
|
<i>site</i> is equal to $<b>myorigin</b>, when <i>site</i> is listed in
|
|
$mydestination, or when it is listed in
|
|
$<i>inet_interfaces</i>.
|
|
|
|
This functionality overlaps with functionality of
|
|
the local <i>alias</i>(5) database. The difference is that
|
|
<b>virtual</b> mapping can be applied to non-local
|
|
addresses.
|
|
|
|
@<i>domain</i> <i>address,</i> <i>address,</i> <i>...</i>
|
|
Mail for any user in <i>domain</i> is redirected to
|
|
<i>address</i>. This form has the lowest precedence.
|
|
|
|
In all the above forms, when <i>address</i> has the form @<i>other-</i>
|
|
<i>domain</i>, the result is the same user in <i>otherdomain</i>. This
|
|
works for the first address in the expansion only.
|
|
|
|
<b>ADDRESS</b> <b>EXTENSION</b>
|
|
When a mail address localpart contains the optional recip-
|
|
ient delimiter (e.g., <i>user+foo</i>@<i>domain</i>), the lookup order
|
|
becomes: <i>user+foo</i>@<i>domain</i>, <i>user</i>@<i>domain</i>, <i>user+foo</i>, <i>user</i>, and
|
|
@<i>domain</i>. An unmatched address extension (<i>+foo</i>) is propa-
|
|
gated to the result of table lookup.
|
|
|
|
<b>REGULAR</b> <b>EXPRESSION</b> <b>TABLES</b>
|
|
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 <a href="regexp_table.5.html"><b>regexp</b><i>_</i><b>table</b>(5)</a> or <a href="pcre_table.5.html"><b>pcre</b><i>_</i><b>table</b>(5)</a>.
|
|
|
|
Each pattern is a regular expression that is applied to
|
|
the entire address being looked up. Thus, <i>user@domain</i> mail
|
|
addresses are not broken up into their <i>user</i> and <i>@domain</i>
|
|
constituent parts, nor is <i>user+foo</i> broken up into <i>user</i> and
|
|
<i>foo</i>.
|
|
|
|
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 <b>$1</b>, <b>$2</b> and so on.
|
|
|
|
<b>BUGS</b>
|
|
The table format does not understand quoting conventions.
|
|
|
|
<b>CONFIGURATION</b> <b>PARAMETERS</b>
|
|
The following <b>main.cf</b> parameters are especially relevant
|
|
to this topic. See the Postfix <b>main.cf</b> file for syntax
|
|
details and for default values. Use the <b>postfix</b> <b>reload</b>
|
|
command after a configuration change.
|
|
|
|
<b>virtual</b><i>_</i><b>maps</b>
|
|
List of virtual mapping tables.
|
|
|
|
Other parameters of interest:
|
|
|
|
<b>inet</b><i>_</i><b>interfaces</b>
|
|
The network interface addresses that this system
|
|
receives mail on.
|
|
|
|
<b>mydestination</b>
|
|
List of domains that this mail system considers
|
|
local.
|
|
|
|
<b>myorigin</b>
|
|
The domain that is appended to locally-posted mail.
|
|
|
|
<b>owner</b><i>_</i><b>request</b><i>_</i><b>special</b>
|
|
Give special treatment to <b>owner-</b><i>xxx</i> and <i>xxx</i><b>-request</b>
|
|
addresses.
|
|
|
|
<b>SEE</b> <b>ALSO</b>
|
|
<a href="cleanup.8.html">cleanup(8)</a> canonicalize and enqueue mail
|
|
<a href="postmap.1.html">postmap(1)</a> create mapping table
|
|
<a href="pcre_table.5.html">pcre_table(5)</a> format of PCRE tables
|
|
<a href="regexp_table.5.html">regexp_table(5)</a> format of POSIX regular expression tables
|
|
|
|
<b>LICENSE</b>
|
|
The Secure Mailer license must be distributed with this
|
|
software.
|
|
|
|
<b>AUTHOR(S)</b>
|
|
Wietse Venema
|
|
IBM T.J. Watson Research
|
|
P.O. Box 704
|
|
Yorktown Heights, NY 10598, USA
|
|
|
|
1
|
|
|
|
</pre> </body> </html>
|