This is a variation on the Postfix
virtual mailbox example.
Again, every hosted address can have its own mailbox.
While non-Postfix software is being used for final delivery,
some Postfix concepts are still needed in order to glue everything
together. For additional background on this glue you may want to
take a look at the
virtual mailbox domain class as defined in the
The text in this section describes what things should look like
from Postfix's point of view. See
for specific information about Cyrus or about Courier maildrop.
Here is an example for a
hosted domain example.com that delivers
to a non-Postfix delivery agent:
virtual_transport = ...see below...
virtual_mailbox_domains = example.com ...more domains...
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_alias_maps = hash:/etc/postfix/virtual
8 [email protected] whatever
9 [email protected] whatever
10 # Comment out the entry below to implement a catch-all.
11 # Configure the mailbox store to accept all addresses.
12 # @example.com whatever
13 ...virtual mailboxes for more domains...
16 [email protected] postmaster
Line 2: With delivery to a non-Postfix mailbox store for
hosted domains, the
virtual_transport parameter usually specifies
the Postfix LMTP client, or the name of a master.cf entry that
executes non-Postfix software via the pipe delivery agent. Typical
examples (use only one):
lmtp:unix:/path/name (uses UNIX-domain socket)
lmtp:hostname:port (uses TCP socket)
virtual_transport = maildrop: (uses
pipe(8) to command)
Postfix comes ready with support for LMTP. And an example
maildrop delivery method is already defined in the default Postfix
master.cf file. See the
MAILDROP_README document for more details.
Line 3: The
virtual_mailbox_domains setting tells Postfix
that example.com is delivered via the
virtual_transport that was
discussed in the previous paragraph. If you omit this
virtual_mailbox_domains setting then Postfix will either reject
mail (relay access denied) or will not be able to deliver it (mail
for example.com loops back to myself).
NEVER list a
virtual MAILBOX domain name as a
NEVER list a
virtual MAILBOX domain name as a virtual ALIAS
Lines 4, 7-13: The
virtual_mailbox_maps parameter specifies
the lookup table with all valid recipient addresses. The lookup
result is ignored by Postfix. In the above example, [email protected]
and [email protected] are listed as valid addresses, and mail for
anything else is rejected with "User unknown". If you intend to
use LDAP, MySQL or PgSQL instead of local files, be sure to review
"local files versus databases"
section at the top of this document!
Line 12: The commented out entry (text after #) shows how
one would inform Postfix of the existence of a catch-all address.
Again, the lookup result is ignored by Postfix.
NEVER put a virtual MAILBOX wild-card in the virtual ALIAS
Note: if you specify a wildcard in
you still need to configure the non-Postfix mailbox store to receive
mail for any address in that domain.
Lines 5, 15, 16: As you see above, it is possible to mix
virtual aliases with virtual mailboxes. We use this feature to
redirect mail for example.com's postmaster address to the local
postmaster. You can use the same mechanism to redirect any addresses
to a local or remote address.
Line 16: This example assumes that in main.cf, $
is listed under the
mydestination parameter setting. If that is
not the case, specify an explicit domain name on the right-hand
side of the virtual alias table entries or else mail will go to
the wrong domain.
Execute the command "postmap /etc/postfix/virtual" after
changing the virtual file, execute "postmap /etc/postfix/vmailbox"
after changing the vmailbox file, and execute the command "postfix
reload" after changing the main.cf file.