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
ADDRESS_CLASS_README file.
The text in this section describes what things should look like
from Postfix's point of view. See
CYRUS_README or
MAILDROP_README
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:
1 /etc/postfix/main.cf:
2
virtual_transport = ...see below...
3
virtual_mailbox_domains = example.com ...more domains...
4
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
5
virtual_alias_maps = hash:/etc/postfix/virtual
6
7 /etc/postfix/vmailbox:
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...
14
15 /etc/postfix/virtual:
16 [email protected] postmaster
Notes:
-
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):
virtual_transport =
lmtp:unix:/path/name (uses UNIX-domain socket)
virtual_transport =
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
mydestination
domain!
NEVER list a
virtual MAILBOX domain name as a virtual ALIAS
domain!
-
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
the
"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
file!!
Note: if you specify a wildcard in
virtual_mailbox_maps, then
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, $
myorigin
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.
