NetBSD/gnu/dist/postfix/html/ADDRESS_REWRITING_README.html

1065 lines
40 KiB
HTML

<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Postfix Address Rewriting </title>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix
Address Rewriting </h1>
<hr>
<h2> <a name="purpose"> Postfix address rewriting purpose </a> </h2>
<p> Address rewriting is at the heart of the Postfix mail system.
Postfix rewrites addresses for many different purposes. Some are
merely cosmetic, and some are necessary to deliver correctly
formatted mail to the correct destination. Examples of
address rewriting in Postfix are: </p>
<ul>
<li> <p> Transform an incomplete address into a complete address.
For example, transform "username" into "username@example.com", or
transform "username@hostname" into "username@hostname.example.com".
</p>
<li> <p> Replace an address by an equivalent address. For example,
replace "username@example.com" by "firstname.lastname@example.com"
when sending mail, and do the reverse transformation when receiving
mail. </p>
<li> <p> Replace an address by multiple addresses. For example,
replace the address of an alias by the addresses listed under that
alias. </p>
<li> <p> Determine how and where to deliver mail for a specific
address. For example, deliver mail for "username@example.com" with
the <a href="smtp.8.html">smtp(8)</a> delivery agent, to the hosts that are listed in the
DNS as the mail servers for the domain "example.com". </p>
</ul>
<p> Although Postfix currently has no address rewriting language,
it can do surprisingly powerful address manipulation via table
lookup. Postfix typically uses lookup tables with fixed strings
to map one address to one or multiple addresses, and typically uses
regular expressions to map multiple addresses to one or multiple
addresses. Fixed-string lookup tables may be in the form of local
files, or in the form of NIS, LDAP or SQL databases. The
<a href="DATABASE_README.html">DATABASE_README</a> document gives an introduction to Postfix lookup
tables. </p>
<p> Topics covered in this document: </p>
<ul>
<li> <a href="#overview"> Postfix address rewriting overview </a>
<li> <a href="#receiving"> Address rewriting when mail is received</a>
<ul>
<li> <a href="#standard"> Rewrite addresses to standard form</a>
<li> <a href="#canonical"> Canonical address mapping </a>
<li> <a href="#masquerade"> Address masquerading </a>
<li> <a href="#auto_bcc"> Automatic BCC recipients</a>
<li> <a href="#virtual"> Virtual aliasing </a>
</ul>
<li> <a href="#delivering"> Address rewriting when mail is delivered</a>
<ul>
<li> <a href="#resolve"> Resolve address to destination </a>
<li> <a href="#transport"> Mail transport switch </a>
<li> <a href="#relocated"> Relocated users table </a>
<li> <a href="#aliases"> Local alias database </a>
<li> <a href="#forward"> Local per-user .forward files </a>
<li> <a href="#luser_relay"> Local catch-all address </a>
</ul>
<li> <a href="#debugging"> Debugging your address manipulations </a>
</ul>
<h2> <a name="overview"> Postfix address rewriting overview </a> </h2>
<p> The figure below zooms in on those parts of Postfix that are most
involved with address rewriting activity. See the <a href="OVERVIEW.html">OVERVIEW</a> document
for an overview of the complete Postfix architecture. Names followed
by a number are Postfix daemon programs, while unnumbered names
represent Postfix queues or internal sources of mail messages. </p>
<blockquote>
<table>
<tr>
<td colspan="2"> </td>
<td bgcolor="#f0f0ff" align="center"> <a href="trivial-rewrite.8.html">trivial-<br>rewrite(8)</a><br>(std
form) </td>
<td colspan="5"> </td>
<td bgcolor="#f0f0ff" align="center"> <a href="trivial-rewrite.8.html">trivial-<br>rewrite(8)</a><br>(resolve)
</td>
</tr>
<tr>
<td colspan="2"> </td>
<td align="center"><table><tr><td align="center"> ^<br> <tt> |
</tt> </td><td align="center"> <tt> |<br>v </tt> </td></tr></table>
<td colspan="5"> </td>
<td align="center"><table><tr><td align="center"> ^<br> <tt> |
</tt> </td><td align="center"> <tt> |<br>v </tt> </td></tr></table>
<td colspan="2"> </td>
</tr>
<tr>
<td bgcolor="#f0f0ff" align="center" valign="middle"> <a href="smtpd.8.html">smtpd(8)</a>
</td>
<td rowspan="3" align="center" valign="middle"> <tt> &gt;- </tt>
</td>
<td rowspan="3" bgcolor="#f0f0ff" align="center"> <a href="cleanup.8.html">cleanup(8)</a> </td>
<td rowspan="3" align="center" valign="middle"> <tt> -&gt; </tt>
</td>
<td rowspan="3" bgcolor="#f0f0ff" align="center"> <a
href="QSHAPE_README.html#incoming_queue"> incoming </a> </td>
<td rowspan="3" align="center" valign="middle"> <tt> -&gt; </tt>
</td>
<td rowspan="3" bgcolor="#f0f0ff" align="center"> <a
href="QSHAPE_README.html#active_queue"> active </a> </td>
<td rowspan="3" align="center" valign="middle"> <tt> -&gt; </tt>
</td>
<td rowspan="3" bgcolor="#f0f0ff" align="center"> <a href="qmgr.8.html">qmgr(8)</a> </td>
<td rowspan="3" align="center" valign="middle"> <tt> -&lt; </tt>
</td>
<td bgcolor="#f0f0ff" align="center" valign="middle">
<a href="smtp.8.html">smtp(8)</a> </td>
</tr>
<tr>
<td bgcolor="#f0f0ff" align="center" valign="middle">
<a href="qmqpd.8.html">qmqpd(8)</a> </td>
<td bgcolor="#f0f0ff" align="center" valign="middle"> <a href="lmtp.8.html">lmtp(8)</a> </td>
</tr>
<tr>
<td bgcolor="#f0f0ff" align="center" valign="middle"> <a href="pickup.8.html">pickup(8)</a>
</td>
<td bgcolor="#f0f0ff" align="center" valign="middle"> <a href="local.8.html">local(8)</a>
</td>
</tr>
<tr>
<td colspan="2"> </td>
<td align="center"> ^<br> <tt> | </tt> </td>
<td colspan="3"> </td>
<td align="center"><table><tr><td align="center"> ^<br> <tt> |
</tt> </td><td align="center"> <tt> |<br>v </tt> </td></tr></table>
<td colspan="4"> </td>
</tr>
<tr>
<td colspan="2"> </td>
<td align="center"> bounces<br> forwarding<br> notices</td>
<td colspan="3"> </td>
<td bgcolor="#f0f0ff" align="center"> <a
href="QSHAPE_README.html#deferred_queue"> deferred </a>
<td colspan="2"> </td>
</table>
</blockquote>
<p> The table below summarizes all Postfix address manipulations.
If you're reading this document for the first time, skip forward
to "<a href="ADDRESS_REWRITING_README.html#receiving">Address
rewriting when mail is received</a>". Once you've finished reading
the remainder of this document, the table will help you to quickly
find what you need. </p>
<blockquote>
<table border="1">
<tr> <th nowrap> Address manipulation </th> <th nowrap> Scope </th>
<th> Daemon </th> <th nowrap> Global turn-on control </th> <th nowrap> Selective
turn-off control </th> </tr>
<tr> <td> <a href="#standard"> Rewrite addresses to standard form</a>
</td> <td nowrap> all mail </td> <td> <a href="trivial-rewrite.8.html">trivial-<br>rewrite(8)</a> </td>
<td> <a href="postconf.5.html#append_at_myorigin">append_at_myorigin</a>, <a href="postconf.5.html#append_dot_mydomain">append_dot_mydomain</a>, <a href="postconf.5.html#swap_bangpath">swap_bangpath</a>,
<a href="postconf.5.html#allow_percent_hack">allow_percent_hack</a> </td> <td> none </td> </tr>
<tr> <td> <a href="#canonical"> Canonical address mapping </a>
</td> <td nowrap> all mail </td> <td> <a href="cleanup.8.html">cleanup(8)</a> </td> <td>
<a href="postconf.5.html#canonical_maps">canonical_maps</a> </td> <td> <a href="postconf.5.html#receive_override_options">receive_override_options</a> </td> </tr>
<tr> <td> <a href="#canonical"> Address masquerading </a> </td>
<td nowrap> all mail </td> <td> <a href="cleanup.8.html">cleanup(8)</a> </td> <td> <a href="postconf.5.html#masquerade_domains">masquerade_domains</a>
</td> <td> <a href="postconf.5.html#receive_override_options">receive_override_options</a> </td> </tr>
<tr> <td> <a href="#auto_bcc"> Automatic BCC recipients </a> </td>
<td nowrap> new mail </td> <td> <a href="cleanup.8.html">cleanup(8)</a> </td> <td> <a href="postconf.5.html#always_bcc">always_bcc</a>,
<a href="postconf.5.html#sender_bcc_maps">sender_bcc_maps</a>, <a href="postconf.5.html#recipient_bcc_maps">recipient_bcc_maps</a> </td> <td> <a href="postconf.5.html#receive_override_options">receive_override_options</a>
</td> </tr>
<tr> <td> <a href="#virtual"> Virtual aliasing </a> </td> <td
nowrap> all mail </td> <td> <a href="cleanup.8.html">cleanup(8)</a> </td> <td> <a href="postconf.5.html#virtual_alias_maps">virtual_alias_maps</a>
</td> <td> <a href="postconf.5.html#receive_override_options">receive_override_options</a> </td> </tr>
<tr> <td> <a href="#resolve"> Resolve address to destination </a>
</td> <td nowrap> all mail </td> <td> <a href="trivial-rewrite.8.html">trivial-<br>rewrite(8)</a> </td>
<td> none </td> <td> none </td> </tr>
<tr> <td> <a href="#transport"> Mail transport switch</a> </td>
<td nowrap> all mail </td> <td> <a href="trivial-rewrite.8.html">trivial-<br>rewrite(8)</a> </td> <td>
<a href="postconf.5.html#transport_maps">transport_maps</a> </td> <td> none </td> </tr>
<tr> <td> <a href="#relocated"> Relocated users table</a> </td>
<td nowrap> all mail </td> <td> <a href="trivial-rewrite.8.html">trivial-<br>rewrite(8)</a> </td> <td>
<a href="postconf.5.html#relocated_maps">relocated_maps</a> </td> <td> none </td> </tr>
<tr> <td> <a href="#aliases"> Local alias database</a> </td> <td>
all mail </td> <td> <a href="local.8.html">local(8)</a> </td> <td> <a href="postconf.5.html#alias_maps">alias_maps</a> </td> <td> none
</td> </tr>
<tr> <td> <a href="#forward"> Local per-user .forward files</a>
</td> <td> all mail </td> <td> <a href="local.8.html">local(8)</a> </td> <td> <a href="postconf.5.html#forward_path">forward_path</a>
</td> <td> none </td> </tr>
<tr> <td> <a href="#luser_relay"> Local catch-all address</a> </td>
<td> all mail </td> <td> <a href="local.8.html">local(8)</a> </td> <td> <a href="postconf.5.html#luser_relay">luser_relay</a> </td> <td>
none </td> </tr>
</table>
</blockquote>
<h2> <a name="receiving"> Address rewriting when mail is received</a> </h2>
<p> The <a href="cleanup.8.html">cleanup(8)</a> server receives mail from outside of Postfix as
well as mail from internal sources such as forwarded mail,
undeliverable mail that is bounced to the sender, and postmaster
notifications about problems with the mail system. </p>
<p> The <a href="cleanup.8.html">cleanup(8)</a> server transforms the sender, recipients and
message content into a standard form before writing it to an incoming
queue file. The server cleans up sender and recipient addresses in
message headers and in the envelope, adds missing message headers
such as From: or Date: that are required by mail standards, and
removes message headers such as Bcc: that should not be present.
The <a href="cleanup.8.html">cleanup(8)</a> server delegates the more complex address manipulations
to the <a href="trivial-rewrite.8.html">trivial-rewrite(8)</a> server as described later in this document.
</p>
<p> Address manipulations at this stage are: </p>
<ul>
<li> <a href="#standard"> Rewrite addresses to standard form</a>
<li> <a href="#canonical"> Canonical address mapping</a>
<li> <a href="#masquerade"> Address masquerading</a>
<li> <a href="#auto_bcc"> Automatic BCC recipients</a>
<li> <a href="#virtual"> Virtual aliasing </a>
</ul>
<h3> <a name="standard"> Rewrite addresses to standard form</a> </h3>
<p> Before the <a href="cleanup.8.html">cleanup(8)</a> daemon runs an address through any address
mapping lookup table, it first rewrites the address to the standard
"user@fully.qualified.domain" form, by sending the address to the
<a href="trivial-rewrite.8.html">trivial-rewrite(8)</a> daemon. The purpose of rewriting to standard
form is to reduce the number of entries needed in lookup tables.
</p>
<p> The Postfix <a href="trivial-rewrite.8.html">trivial-rewrite(8)</a> daemon implements the following
hard-coded address manipulations: </p>
<blockquote>
<dl>
<dt>Rewrite "@hosta,@hostb:user@site" to "user@site"</dt>
<dd> <p> In case you wonder what this is, the address form above
is called a route address, and specifies that mail for "user@site"
be delivered via "hosta" and "hostb". Usage of this form has been
deprecated for a long time. Postfix has no ability to handle route
addresses, other than to strip off the route part. </p> </dd>
<dt>Rewrite "site!user" to "user@site" </dt>
<dd> <p> This feature is controlled by the boolean <a href="postconf.5.html#swap_bangpath">swap_bangpath</a>
parameter (default: yes). The purpose is to rewrite UUCP-style
addresses to domain style. This is useful only when you receive
mail via UUCP, but it probably does not hurt otherwise. </p> </dd>
<dt>Rewrite "user%domain" to "user@domain"</dt>
<dd> <p> This feature is controlled by the boolean <a href="postconf.5.html#allow_percent_hack">allow_percent_hack</a>
parameter (default: yes). Typically, this is used in order to deal
with monstrosities such as "user%domain@otherdomain". </p>
</dd>
<dt>
Rewrite "user" to "user@$<a href="postconf.5.html#myorigin">myorigin</a>" </dt>
<dd> <p> This feature is controlled by the boolean <a href="postconf.5.html#append_at_myorigin">append_at_myorigin</a>
parameter (default: yes). You should never turn off this feature,
because a lot of Postfix components expect that all addresses have
the form "user@domain". </p>
<p> If your machine is not the main machine for $<a href="postconf.5.html#myorigin">myorigin</a> and you
wish to have some users delivered locally without going via that
main machine, make an entry in the <a href="#virtual">virtual
alias</a> table that redirects "user@$myorigin" to
"user@$<a href="postconf.5.html#myhostname">myhostname</a>". See also the "delivering some
users locally" section in the <a href="STANDARD_CONFIGURATION_README.html">STANDARD_CONFIGURATION_README</a>
document. </p> </dd>
<dt>
Rewrite "user@host" to "user@host.$<a href="postconf.5.html#mydomain">mydomain</a>" </dt>
<dd> <p> This feature is controlled by the boolean <a href="postconf.5.html#append_dot_mydomain">append_dot_mydomain</a>
parameter (default: yes). The purpose is to get consistent treatment
of different forms of the same hostname. </p>
<p> Some will argue that rewriting "host" to "host.$<a href="postconf.5.html#mydomain">mydomain</a>"
is bad. That is why it can be turned off. Others like the convenience
of having the <a href="ADDRESS_CLASS_README.html#local_domain_class">local domain</a> appended automatically. </p> </dd>
<dt>Rewrite "user@site." to "user@site" (without the trailing dot).</dt>
<dd> <p> A single trailing dot is silently removed. However, an
address that ends in multiple dots will be rejected as an invalid
address. </p> </dd>
</dl>
</blockquote>
<h3> <a name="canonical"> Canonical address mapping </a> </h3>
<p> The <a href="cleanup.8.html">cleanup(8)</a> daemon uses the <a href="canonical.5.html">canonical(5)</a> tables to rewrite
all addresses in message envelopes and in message headers. This is
done for local and remote addresses. The mapping is useful to
replace login names by "Firstname.Lastname" style addresses, or to
clean up invalid domains in mail addresses produced by legacy mail
systems. </p>
<p> Canonical mapping is disabled by default. To enable, edit the
<a href="postconf.5.html#canonical_maps">canonical_maps</a> parameter in the main.cf file and specify one or
more lookup tables, separated by whitespace or commas. </p>
<p> Example: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
<a href="postconf.5.html#canonical_maps">canonical_maps</a> = hash:/etc/postfix/canonical
/etc/postfix/canonical:
wietse Wietse.Venema
</pre>
</blockquote>
<p> For static mappings as shown above, lookup tables such as hash:,
<a href="ldap_table.5.html">ldap</a>:, <a href="mysql_table.5.html">mysql</a>: or <a href="pgsql_table.5.html">pgsql</a>: are sufficient. For dynamic mappings you
can use regular expression tables. This requires that you become
intimately familiar with the ideas expressed in <a href="regexp_table.5.html">regexp_table(5)</a>,
<a href="pcre_table.5.html">pcre_table(5)</a> and <a href="canonical.5.html">canonical(5)</a>. </p>
<p> In addition to the canonical maps which are applied to both sender
and recipient addresses, you can specify canonical maps that are
applied only to sender addresses or to recipient addresses. </p>
<p> Example: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
<a href="postconf.5.html#sender_canonical_maps">sender_canonical_maps</a> = hash:/etc/postfix/sender_canonical
<a href="postconf.5.html#recipient_canonical_maps">recipient_canonical_maps</a> = hash:/etc/postfix/recipient_canonical
</pre>
</blockquote>
<p> The sender and recipient canonical maps are applied before the
common canonical maps. </p>
<p> Sender-specific rewriting is useful when you want to rewrite
ugly sender addresses to pretty ones, and still want to be able to
send mail to the those ugly address without creating a mailer loop.
</p>
<p> Canonical mapping can be turned off selectively for mail received
by <a href="smtpd.8.html">smtpd(8)</a>, <a href="qmqpd.8.html">qmqpd(8)</a>, or <a href="pickup.8.html">pickup(8)</a>, by overriding main.cf settings
in the master.cf file. This feature is available in Postfix version
2.1 and later. </p>
<p> Example: </p>
<blockquote>
<pre>
/etc/postfix/master.cf:
:10026 inet n - n - - smtpd
-o <a href="postconf.5.html#receive_override_options">receive_override_options</a>=no_address_mapping
</pre>
</blockquote>
<p> Note: do not specify whitespace around the "=" here. </p>
<h3> <a name="masquerade"> Address masquerading </a> </h3>
<p> Address masquerading is a method to hide hosts inside a domain
behind their mail gateway, and to make it appear as if the mail
comes from the gateway itself, instead of from individual machines.
</p>
<p> Address masquerading is disabled by default, and is implemented
by the <a href="cleanup.8.html">cleanup(8)</a> server. To enable, edit the <a href="postconf.5.html#masquerade_domains">masquerade_domains</a>
parameter in the main.cf file and specify one or more domain names
separated by whitespace or commas. When Postfix tries to masquerade
a domain, it processes the list from left to right, and processing
stops at the first match. </p>
<p> Example: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
<a href="postconf.5.html#masquerade_domains">masquerade_domains</a> = foo.example.com example.com
</pre>
</blockquote>
<p> strips "any.thing.foo.example.com" to "foo.example.com", but
strips "any.thing.else.example.com" to "example.com". </p>
<p> A domain name prefixed with "<tt>!</tt>" means do not masquerade
this domain or its subdomains: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
<a href="postconf.5.html#masquerade_domains">masquerade_domains</a> = !foo.example.com example.com
</pre>
</blockquote>
<p> does not change "any.thing.foo.example.com" and "foo.example.com",
but strips "any.thing.else.example.com" to "example.com". </p>
<p> The <a href="postconf.5.html#masquerade_exceptions">masquerade_exceptions</a> configuration parameter specifies
what user names should not be subjected to address masquerading.
Specify one or more user names separated by whitespace or commas.
</p>
<p> Example: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
<a href="postconf.5.html#masquerade_exceptions">masquerade_exceptions</a> = root
</pre>
</blockquote>
<p> By default, Postfix makes no exceptions. </p>
<p> Subtle point: by default, address masquerading is applied only to
message headers and to envelope sender addresses, but not to envelope
recipients. This allows you to use address masquerading on a mail
gateway machine, while still being able to forward mail from outside
to users on individual machines. </p>
<p> In order to subject envelope recipient addresses to masquerading,
too, specify (Postfix version 1.1 and later):</p>
<blockquote>
<pre>
/etc/postfix/main.cf:
<a href="postconf.5.html#masquerade_classes">masquerade_classes</a> = envelope_sender, envelope_recipient,
header_sender, header_recipient
</pre>
</blockquote>
<p> If you rewrite the envelope recipient like this, Postfix will
no longer be able to send mail to individual machines. </p>
<p> Address masquerading can be turned off selectively for mail
received by <a href="smtpd.8.html">smtpd(8)</a>, <a href="qmqpd.8.html">qmqpd(8)</a>, or <a href="pickup.8.html">pickup(8)</a>, by overriding main.cf
settings in the master.cf file. This feature is available in
Postfix version 2.1 and later. </p>
<p> Example: </p>
<blockquote>
<pre>
/etc/postfix/master.cf:
:10026 inet n - n - - smtpd
-o <a href="postconf.5.html#receive_override_options">receive_override_options</a>=no_address_mapping
</pre>
</blockquote>
<p> Note: do not specify whitespace around the "=" here. </p>
<h3> <a name="auto_bcc"> Automatic BCC recipients</a> </h3>
<p> After applying the canonical and masquerade mappings, the
<a href="cleanup.8.html">cleanup(8)</a> daemon can generate optional BCC (blind carbon-copy)
recipients. Postfix provides three mechanisms: </p>
<blockquote>
<dl>
<dt> <a href="postconf.5.html#always_bcc">always_bcc</a> = address </dt> <dd> Deliver a copy of all mail to
the specified address. In Postfix versions before 2.1, this feature
is implemented by <a href="smtpd.8.html">smtpd(8)</a>, <a href="qmqpd.8.html">qmqpd(8)</a>, or <a href="pickup.8.html">pickup(8)</a>. </dd>
<dt> <a href="postconf.5.html#sender_bcc_maps">sender_bcc_maps</a> = type:table </dt> <dd> Search the specified
"<a href="DATABASE_README.html">type:table</a>" lookup table with the envelope sender address for an
automatic BCC address. This feature is available in Postfix 2.1
and later. </dd>
<dt> <a href="postconf.5.html#recipient_bcc_maps">recipient_bcc_maps</a> = type:table </dt> <dd> Search the specified
"<a href="DATABASE_README.html">type:table</a>" lookup table with the envelope recipient address for
an automatic BCC address. This feature is available in Postfix 2.1
and later. </dd>
</dl>
</blockquote>
<p> Note: automatic BCC recipients are produced only for new mail.
To avoid mailer loops, automatic BCC recipients are not generated
for mail that Postfix forwards internally, nor for mail that Postfix
generates itself. </p>
<p> Automatic BCC recipients (including <a href="postconf.5.html#always_bcc">always_bcc</a>) can be turned
off selectively for mail received by <a href="smtpd.8.html">smtpd(8)</a>, <a href="qmqpd.8.html">qmqpd(8)</a>, or <a href="pickup.8.html">pickup(8)</a>,
by overriding main.cf settings in the master.cf file. This feature
is available in Postfix version 2.1 and later. </p>
<p> Example: </p>
<blockquote>
<pre>
/etc/postfix/master.cf:
:10026 inet n - n - - smtpd
-o <a href="postconf.5.html#receive_override_options">receive_override_options</a>=no_address_mapping
</pre>
</blockquote>
<p> Note: do not specify whitespace around the "=" here. </p>
<h3> <a name="virtual"> Virtual aliasing </a> </h3>
<p> Before writing the recipients to the queue file, the <a href="cleanup.8.html">cleanup(8)</a>
daemon uses the optional <a href="virtual.5.html">virtual(5)</a> alias tables to redirect mail
for recipients. The mapping affects only envelope recipient
addresses; it has no effect on message headers or envelope sender
addresses. Virtual alias lookups are useful to redirect mail for
<a href="ADDRESS_CLASS_README.html#virtual_alias_class">virtual alias domains</a> to real user mailboxes, and to redirect mail
for domains that no longer exist. Virtual alias lookups can also
be used to transform " Firstname.Lastname " back into UNIX login
names, although it seems that local <a href="#aliases">aliases</a>
may be a more appropriate vehicle. See the <a href="VIRTUAL_README.html">VIRTUAL_README</a> document
for an overview of methods to host virtual domains with Postfix.
</p>
<p> Virtual aliasing is disabled by default. To enable, edit the
<a href="postconf.5.html#virtual_alias_maps">virtual_alias_maps</a> parameter in the main.cf file and
specify one or more lookup tables, separated by whitespace or
commas. </p>
<p> Example: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
<a href="postconf.5.html#virtual_alias_maps">virtual_alias_maps</a> = hash:/etc/postfix/virtual
/etc/postfix/virtual:
Wietse.Venema wietse
</pre>
</blockquote>
<p> Addresses found in virtual alias maps are subjected to another
iteration of virtual aliasing, but are not subjected to canonical
mapping, in order to avoid loops. </p>
<p> For static mappings as shown above, lookup tables such as hash:,
<a href="ldap_table.5.html">ldap</a>:, <a href="mysql_table.5.html">mysql</a>: or <a href="pgsql_table.5.html">pgsql</a>: are sufficient. For dynamic mappings you
can use regular expression tables. This requires that you become
intimately familiar with the ideas expressed in <a href="regexp_table.5.html">regexp_table(5)</a>,
<a href="pcre_table.5.html">pcre_table(5)</a> and <a href="virtual.5.html">virtual(5)</a>. </p>
<p> Note: automatic BCC recipients are produced only for new mail.
To avoid mailer loops, automatic BCC recipients are not generated
for mail that is forwarded internally, and are not generated for
mail that is generated by Postfix itself. </p>
<p> Virtual aliasing can be turned off selectively for mail received
by <a href="smtpd.8.html">smtpd(8)</a>, <a href="qmqpd.8.html">qmqpd(8)</a>, or <a href="pickup.8.html">pickup(8)</a>, by overriding main.cf settings
in the master.cf file. This feature is available in Postfix version
2.1 and later. </p>
<p> Example: </p>
<blockquote>
<pre>
/etc/postfix/master.cf:
:10026 inet n - n - - smtpd
-o <a href="postconf.5.html#receive_override_options">receive_override_options</a>=no_address_mapping
</pre>
</blockquote>
<p> Note: do not specify whitespace around the "=" here. </p>
<p> At this point the message is ready to be stored into the
Postfix <a href="QSHAPE_README.html#incoming_queue">incoming queue</a>. </p>
<h2> <a name="delivering"> Address rewriting when mail is delivered</a> </h2>
<p> The Postfix queue manager sorts mail according to its destination
and gives it to Postfix delivery agents such as <a href="local.8.html">local(8)</a>, <a href="smtp.8.html">smtp(8)</a>,
or <a href="lmtp.8.html">lmtp(8)</a>. Just like the <a href="cleanup.8.html">cleanup(8)</a> server, the Postfix queue
manager delegates the more complex address manipulations to the
<a href="trivial-rewrite.8.html">trivial-rewrite(8)</a> server. </p>
<p> Address manipulations at this stage are: </p>
<ul>
<li> <a href="#resolve"> Resolve address to destination </a>
<li> <a href="#transport"> Mail transport switch</a>
<li> <a href="#relocated"> Relocated users table</a>
</ul>
<p> Each Postfix delivery agent tries to deliver the mail to its
destination, while encapsulating the sender, recipients, and message
content according to the rules of the SMTP, LMTP, etc. protocol.
When mail cannot be delivered, it is either returned to the sender
or moved to the <a href="QSHAPE_README.html#deferred_queue">deferred queue</a> and tried again later. </p>
<p> Address manipulations when mail is delivered via the <a href="local.8.html">local(8)</a>
delivery agent: </p>
<ul>
<li> <a href="#aliases"> Local alias database</a>
<li> <a href="#forward"> Local per-user .forward files</a>
<li> <a href="#luser_relay"> Local catch-all address</a>
</ul>
<p> The remainder of this document presents each address manipulation
step in more detail, with specific examples or with pointers to
documentation with examples. </p>
<h3> <a name="resolve"> Resolve address to destination </a> </h3>
<p> The Postfix <a href="qmgr.8.html">qmgr(8)</a> queue manager selects new mail from the
<a href="QSHAPE_README.html#incoming_queue">incoming queue</a> or old mail from the <a href="QSHAPE_README.html#deferred_queue">deferred queue</a>, and asks the
<a href="trivial-rewrite.8.html">trivial-rewrite(8)</a> address rewriting and resolving daemon where it
should be delivered. </p>
<p> As of version 2.0, Postfix distinguishes four major address
classes. Each class has its own list of domain names, and each
class has its own default delivery method, as shown in the table
below. See the <a href="ADDRESS_CLASS_README.html">ADDRESS_CLASS_README</a> document for the fine details.
Postfix versions before 2.0 only distinguish between local delivery
and everything else. </p>
<blockquote>
<table border="1">
<tr><th align="left">Destination domain list </th> <th
align="left">Default delivery method </th> <th>Availability
</th> </tr>
<tr><td>$<a href="postconf.5.html#mydestination">mydestination</a>, $<a href="postconf.5.html#inet_interfaces">inet_interfaces</a>, $<a href="postconf.5.html#proxy_interfaces">proxy_interfaces</a> </td>
<td>$<a href="postconf.5.html#local_transport">local_transport</a> </td> <td>Postfix 1.0</td></tr>
<tr><td>$<a href="postconf.5.html#virtual_mailbox_domains">virtual_mailbox_domains</a> </td> <td>$<a href="postconf.5.html#virtual_transport">virtual_transport</a> </td>
<td>Postfix 2.0</td> </tr>
<tr><td>$<a href="postconf.5.html#relay_domains">relay_domains</a> </td> <td>$<a href="postconf.5.html#relay_transport">relay_transport</a> </td> <td>Postfix
2.0</td> </tr>
<tr><td>none </td> <td>$<a href="postconf.5.html#default_transport">default_transport</a> </td> <td>Postfix 1.0</td>
</tr>
</table>
</blockquote>
<h3> <a name="transport"> Mail transport switch </a> </h3>
<p> Once the <a href="trivial-rewrite.8.html">trivial-rewrite(8)</a> daemon has determined a default
delivery method it searches the optional <a href="transport.5.html">transport(5)</a> table for
information that overrides the message destination and/or delivery
method. Typical use of the <a href="transport.5.html">transport(5)</a> is to send mail to a system
that is not connected to the Internet, or to use a special SMTP
client configuration for destinations that have special requirements.
See, for example, the <a href="STANDARD_CONFIGURATION_README.html">STANDARD_CONFIGURATION_README</a> and <a href="UUCP_README.html">UUCP_README</a>
documents, and the examples in the <a href="transport.5.html">transport(5)</a> manual page. </p>
<p> Transport table lookups are disabled by default. To enable,
edit the <a href="postconf.5.html#transport_maps">transport_maps</a> parameter in the main.cf file and specify
one or more lookup tables, separated by whitespace or commas. </p>
<p> Example: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
<a href="postconf.5.html#transport_maps">transport_maps</a> = hash:/etc/postfix/transport
</pre>
</blockquote>
<h3> <a name="relocated"> Relocated users table </a> </h3>
<p> Next, the <a href="trivial-rewrite.8.html">trivial-rewrite(8)</a> address rewriting and resolving
daemon runs each recipient through the <a href="relocated.5.html">relocated(5)</a> database. This
table provides information on how to reach users that no longer
have an account, or what to do with mail for entire domains that
no longer exist. When mail is sent to an address that is listed
in this table, the message is returned to the sender with an
informative message. </p>
<p> The <a href="relocated.5.html">relocated(5)</a> database is searched after <a href="transport.5.html">transport(5)</a>
table lookups, in anticipation of <a href="transport.5.html">transport(5)</a> tables that
can replace one recipient address by a different one. </p>
<p> Lookups of relocated users are disabled by default. To enable,
edit the <a href="postconf.5.html#relocated_maps">relocated_maps</a> parameter in the main.cf file and specify
one or more lookup tables, separated by whitespace or commas. </p>
<p> Example: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
<a href="postconf.5.html#relocated_maps">relocated_maps</a> = hash:/etc/postfix/relocated
/etc/postfix/relocated:
username@example.com otheruser@elsewhere.tld
</pre>
</blockquote>
<p> As of Postfix version 2, mail for a relocated user will be
rejected by the SMTP server with the reason "user has moved to
otheruser@elsewhere.tld". Older Postfix versions will receive the
mail first, and then return it to the sender as undeliverable, with
the same reason. </p>
<h3> <a name="aliases"> Local alias database </a> </h3>
<p> When mail is to be delivered locally, the <a href="local.8.html">local(8)</a> delivery
agent runs each local recipient name through the <a href="aliases.5.html">aliases(5)</a> database.
The mapping does not affect addresses in message headers. Local
aliases are typically used to implement distribution lists, or to
direct mail for standard aliases such as postmaster to real people.
The table can also be used to map "Firstname.Lastname" addresses
to login names. </p>
<p> Alias lookups are enabled by default. The default configuration
depends on the operating system environment, but it is typically
one of the following: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
<a href="postconf.5.html#alias_maps">alias_maps</a> = hash:/etc/aliases
<a href="postconf.5.html#alias_maps">alias_maps</a> = dbm:/etc/aliases, nis:mail.aliases
</pre>
</blockquote>
<p> The pathname of the alias database file is controlled with the
<a href="postconf.5.html#alias_database">alias_database</a> configuration parameter. The value is system dependent.
Usually it is one of the following: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
<a href="postconf.5.html#alias_database">alias_database</a> = hash:/etc/aliases (4.4BSD, LINUX)
<a href="postconf.5.html#alias_database">alias_database</a> = dbm:/etc/aliases (4.3BSD, SYSV&lt;4)
<a href="postconf.5.html#alias_database">alias_database</a> = dbm:/etc/mail/aliases (SYSV4)
</pre>
</blockquote>
<p> An <a href="aliases.5.html">aliases(5)</a> file can specify that mail should be delivered
to a local file, or to a command that receives the message in the
standard input stream. For security reasons, deliveries to command
and file destinations are performed with the rights of the alias
database owner. A default userid, <a href="postconf.5.html#default_privs">default_privs</a>, is used for
deliveries to commands or files in "root"-owned aliases. </p>
<h3> <a name="forward"> Local per-user .forward files </a> </h3>
<p> With delivery via the <a href="local.8.html">local(8)</a> deliver agent, users can control
their own mail delivery by specifying destinations in a file called
.forward in their home directories. The syntax of these files is
the same as with the local <a href="aliases.5.html">aliases(5)</a> file, except that the left-hand
side of the alias (lookup key and colon) are not present. </p>
<h3> <a name="luser_relay"> Local catch-all address </a> </h3>
<p> When the <a href="local.8.html">local(8)</a> delivery agent finds that a message recipient
does not exist, the message is normally returned to the sender ("user
unknown"). Sometimes it is desirable to forward mail for non-existing
recipients to another machine. For this purpose you can specify
an alternative destination with the <a href="postconf.5.html#luser_relay">luser_relay</a> configuration
parameter. </p>
<p> Alternatively, mail for non-existent recipients can be delegated
to an entirely different message transport, as specified with the
<a href="postconf.5.html#fallback_transport">fallback_transport</a> configuration parameter. For details, see the
<a href="local.8.html">local(8)</a> delivery agent documentation. </p>
<p> Note: if you use the <a href="postconf.5.html#luser_relay">luser_relay</a> feature in order to receive
mail for non-UNIX accounts, then you must specify: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
<a href="postconf.5.html#local_recipient_maps">local_recipient_maps</a> =
</pre>
</blockquote>
<p> (i.e. empty) in the main.cf file, otherwise the Postfix SMTP
server will reject mail for non-UNIX accounts with "User unknown
in local recipient table". See the <a href="LOCAL_RECIPIENT_README.html">LOCAL_RECIPIENT_README</a> file
for more information on this.
</p>
<p> <a href="postconf.5.html#luser_relay">luser_relay</a> can specify one address. It is subjected to "$name"
expansions. Examples: </p>
<blockquote>
<dl>
<dt>$user@other.host </dt>
<dd> <p> The bare username, without address extension, is prepended
to "@other.host". For example, mail for "username+foo" is sent to
"username@other.host". </p> </dd>
<dt>$local@other.host </dt>
<dd> <p> The entire original recipient localpart, including address
extension, is prepended to "@other.host". For example, mail for
"username+foo" is sent to "username+foo@other.host". </p> </dd>
<dt>sysadmin+$user </dt>
<dd> <p> The bare username, without address extension, is appended
to "sysadmin". For example, mail for "username+foo" is sent to
"sysadmin+username". </p> </dd>
<dt>sysadmin+$local </dt>
<dd> <p> The entire original recipient localpart, including address
extension, is appended to "sysadmin". For example, mail for
"username+foo" is sent to "sysadmin+username+foo". </p> </dd>
</dl>
</blockquote>
<h2> <a name="debugging"> Debugging your address manipulations </a> </h2>
<p> With Postfix version 2.1 and later you can ask Postfix to
produce mail delivery reports for debugging purposes. These reports
not only show sender/recipient addresses after address rewriting
and alias expansion or forwarding, they also show information about
delivery to mailbox, delivery to non-Postfix command, responses
from remote SMTP servers, and so on. </p>
<p> Postfix can produce two types of mail delivery reports for
debugging: </p>
<ul>
<li> <p> What-if: report what would happen, but do not actually
deliver mail. This mode of operation is requested with: </p>
<pre>
$ <b>/usr/sbin/sendmail -bv address...</b>
Mail Delivery Status Report will be mailed to &lt;your login name&gt;.
</pre>
<li> <p> What happened: deliver mail and report successes and/or
failures, including replies from remote SMTP servers. This mode
of operation is requested with: </p>
<pre>
$ <b>/usr/sbin/sendmail -v address...</b>
Mail Delivery Status Report will be mailed to &lt;your login name&gt;.
</pre>
</ul>
<p> These reports contain information that is generated by Postfix
delivery agents. Since these run as daemon processes and do not
interact with users directly, the result is sent as mail to the
sender of the test message. The format of these reports is practically
identical to that of ordinary non-delivery notifications. </p>
<p> As an example, below is the delivery report that is produced
with the command "sendmail -bv postfix-users@postfix.org". The
first part of the report contains human-readable text. In this
case, mail would be delivered via mail.cloud9.net, and the SMTP
server replies with "250 Ok". Other reports may show delivery
to mailbox, or delivery to non-Postfix command. </p>
<blockquote>
<pre>
Content-Description: Notification
Content-Type: text/plain
This is the Postfix program at host spike.porcupine.org.
Enclosed is the mail delivery report that you requested.
The Postfix program
&lt;postfix-users@postfix.org&gt;: delivery via mail.cloud9.net[168.100.1.4]: 250 Ok
</pre>
</blockquote>
<p> The second part of the report is in machine-readable form, and
includes the following information: </p>
<ul>
<li> The envelope sender address (wietse@porcupine.org).
<li> The envelope recipient address (postfix-users@postfix.org).
If the recipient address was changed by Postfix then Postfix also
includes the original recipient address.
<li> The delivery status.
</ul>
<p> Some details are still preliminary and will change as Postfix
implements the DSN (delivery status notification) standards. </p>
<blockquote>
<pre>
Content-Description: Delivery report
Content-Type: message/delivery-status
Reporting-MTA: dns; spike.porcupine.org
X-Postfix-Queue-ID: 84863BC0E5
X-Postfix-Sender: rfc822; wietse@porcupine.org
Arrival-Date: Tue, 13 Apr 2004 19:27:43 -0400 (EDT)
Final-Recipient: rfc822; postfix-users@postfix.org
Action: deliverable
Status: 2.0.0
Diagnostic-Code: X-Postfix; delivery via mail.cloud9.net[168.100.1.4]: 250 Ok
</pre>
</blockquote>
<p> The third part of the report contains the message that Postfix
would have delivered, including From: and To: message headers, so
that you can see any effects of address rewriting on those. Mail
submitted with "sendmail -bv" has no body content so none is shown
in the example below. </p>
<blockquote>
<pre>
Content-Description: Message
Content-Type: message/rfc822
Received: by spike.porcupine.org (Postfix, from userid 1001)
id 84863BC0E5; Tue, 13 Apr 2004 19:27:43 -0400 (EDT)
Subject: probe
To: postfix-users@postfix.org
Message-Id: &lt;20040413232743.84863BC0E5@spike.porcupine.org&gt;
Date: Tue, 13 Apr 2004 19:27:43 -0400 (EDT)
From: wietse@porcupine.org (Wietse Venema)
</pre>
</blockquote>
</body>
</html>