I will try to set the record straight, with some harmless simplification.
Perhaps some of this (after more polish is applied to the prose) can
be incorporated into VIRTUAL_README or perhaps a suitable new README file.
Domains whose mailboxes reside on another host and for which the current
host is willing to act as a relay by accepting the mail from the sender
and forwarding it (one hop closer) to the final destination. The recipient
address is typically unchanged in transit through a relay. Many relays
operate at arms length and forward "the entire domain", they have
no information about which recipients (local parts of the address) are
valid and which are not.
The set of domains for which Postfix acts as a relay is controlled by the
relay_domains parameter (defaults to $mydestination). The parameter
matches subdomains by default, see parent_domain_matches_subdomains in
Note, that unless the current host is a backup MX (some other host has a
lower MX value) for the relay domain, the relay domain needs an explicit
transport table entry to direct the mail to the appropriate next hop,
otherwise one gets "mail for <address> loops back to myself" errors.
The downside of relaying for another domain where (as is normally the
case) one does not know the set of valid mailboxes, is that junk mail to
invalid addresses is accepted from the sender and is subsequently bounced
to the envelope sender. As junk mail sender addresses are often forged,
the bounces inundate the innocent victim of the forgery. Additionally the
destination domain loses the ability to impose IP address restrictions
based on the connecting IP as the relay masks the real source of the mail.
Whenever possible one should avoid relaying to a domain whose valid
address table is unknown to the relay.
Local domains share the namespace of UNIX user accounts and aliases on the
host. Multiple domains may be "local" in this sense! The actual list of
domains is $mydestination + the set of [a.d.d.r] literals for each IP
address in $inet_interfaces (by default the IP addresses of all the
interfaces of the host).
The hostname of the machine ($myhostname) is typically the primary "local"
domain. Postfix will also by default recognize "localhost.$mydomain" as
being local, any other domains in $mydestination are (Sendmail-style)
virtual domains. In most configurations Postfix accepts mail for "local"
domains from all clients trusted ($mynetworks) or not.
To add a new Sendmail-style virtual domain, add its name to
$mydestination. By default mail for such domains is processed by the
"local" delivery agent. Other delivery agents can be selected by setting
$local_transport or via explicit entries in the transport table.
The "local" delivery agent ignores the domain part of the recipient
address. So all "local" domains (those actually handled by the "local"
delivery agent) are equivalent names for the same local user accounts or
aliases. When the parameter $local_recipient_maps is not empty, the local
parts of addresses in domains matching $mydestination or @[local address]
literals are constrained to be keys in one of the tables that constitute
The checking of $local_recipient_maps is performed for all domains listed
in $mydestination whether or not they are ultimately handled by the
"local" delivery agent. For this reason (and to preserve some measure of
sanity) it is best to have either all or none of the domains in
$mydestination handled by the "local" delivery agent.
When the domains in $mydestination are handled by the "local" delivery
agent, set "local_recipient_maps" to "$alias_maps unix:passwd.byname" as
recommended in the default main.cf file (this setting is commented out by
If the domains in $mydestination are handled by another delivery agent
(e.g. "virtual") one should set local_transport to the appropriate
value. Adding per-domain entries to the transport table is error-prone. In
this case $local_recipient_maps should be left empty. I strongly advise
against adding to $mydestination domains that are not handled by the
"local" delivery agent. It is better to add such domains to $relay_domains
or make them virtual-mailbox domains (see below) as appropriate.
Do not to add the magic "dom.ain whatever" keys to the virtual table or
virtual mailbox table when the domain is listed in $mydestination.
(Postfix-style) Virtual domains:
For every SMTP recipient address in a valid domain there ultimately need
to be one or more hosts that either authoritatively reject the address as
being invalid or deliver mail for the recipient in question. Infinite
relaying of the unmodified address is not an option!
The hosts in question can either terminate the forwarding chain, or
rewrite the recipient address to a new address which may be forwarded to
a different final destination. So long as such rewriting is not circular,
the mail eventually gets delivered.
Postfix supports domains which host only such "forwarding address"
- The host running Postfix is the final destination for all mail
addressed to the domain in question.
- Addresses in the domain are placeholders for forwarding
addresses to *other* domains.
- No final delivery mechanism is available for mailboxes in such a
domain if they are not forwarded to another domain. The domain
is neither "local" nor remote.
Such domains are called Postfix-style virtual domains. They are designated
by adding the domain as key in one of the tables of $virtual_maps. The
table value is ignored, so the value "whatever" or "Postfix style
virtual" or anything else that pleases the administrator may be used.
Postfix automatically accepts mail for Postfix-style virtual domains. They
should not be listed in either $mydestination or $relay_domains.
Every valid address in a Postfix-style virtual domain, must be rewritten
to an address in a non Postfix-style virtual domain. If an address in a
Postfix-style virtual domain is detected by the queue manager (cleanup did
not rewrite the recipient out of the virtual domain) the mail is bounced,
as it can neither be delivered locally nor relayed to another host.
There is a common misconception that "domain whatever" keys are needed in
the virtual table in order to enable virtual table processing of
addresses in the corresponding domain. This is false. Virtual table
rewrites are applied to all recipient addresses even in the absence of
"domain whatever" keys.
Add "domain whatever" keys only to create Postfix-style virtual domains
which only redirect mail to other domains addresses on the host. Do not
use catchall addresses with Postfix-style virtual domains. The catchall
addresses turn the Postfix-style domain into a relay domain because all
recipients become valid (with most rewritten via the catchall table
entry). It is cleaner to drop the "domain whatever" entry and add the
domain to the relay_domains list, while retaining any explicit and
catchall rewrite rules in the virtual table.
An MTA must either reject, deliver, relay or bounce a message. So far we
have discussed relaying, "local" delivery and Postfix-style virtual
domains, which are populated exclusively by "forwarding" addresses to
other either remote or local mailboxes.
The "local" delivery agent is designed to deliver to mailboxes of UNIX
shell users. The delivery takes place with the privileges of the
recipient and potentially runs programs specified by the recipient in a
".forward" file. This provides Sendmail compatibility and gives UNIX shell
users all the necessary rope to perform custom email processing.
The "local" delivery agent is not suitable for POP/IMAP users with no
Postfix 1.1.X supports a new type of virtual domain in combination with a
(somewhat confusingly named) "virtual" delivery agent. Mail to recipients
in such domains is delivered locally without need for relaying or
rewriting, but the user does not need a shell account. Multiple such
domains can be supported on each host, and unlike domains in
$mydestination the local-part namespaces of the various domains are
I call such domains *virtual-mailbox* domains. To define a virtual-mailbox
domain, just a "domain whatever" entry to one of the tables listed in
$virtual_mailbox_maps. For now it is also necessary to add the domain to
the transport table in order to arrange for mail to the domain to be
handled by a suitable virtual delivery agent (presumably but not
necessarily the Postfix "virtual" delivery agent).
Postfix will (normally) accept mail for such domains.
The recipient restrictions permit_auth_destination, check_relay_domains
and reject_unauth_destination combine $mydestination, $relay_domains,
the Postfix-style virtual domains and virtual-mailbox domains to create
the list of domains to which relaying is allowed for all clients.
Mailboxes in these domains do not correspond to local shell users, so the
virtual delivery agent needs explicit delivery instructions for each
mailbox. This is accomplished by listing the appropriate delivery
information for each valid recipient in $virtual_mailbox_maps (and for the
Postfix "virtual" agent also $virtual_uid_maps and $virtual_gid_maps).
Recipients not listed in $virtual_mailbox_maps are rejected as without the
necessary mailbox information delivery is not possible.
It is important to understand that the address validation performed during
the SMTP transaction only cares about the existence of the lookup key
in a $virtual_mailbox_maps table, it does not use the table value. Only
the delivery agent needs the actual value in order to store the mail in a
It is therefore possible to use third-party virtual delivery agents such
as Courier "maildrop" with $virtual_mailbox_maps and virtual-mailbox
domains. One just needs to expose the "maildrop" user database (called
"userdb") as a Postfix map used in $virtual_mailbox_maps. The fact that
the table values are not what the Postfix "virtual" agent expects is not
important. Mail for the domains will be accepted, and recipient validation
will be performed by "smtpd". With suitable transport table entries the
delivery is actually handled by the third-party VDA (virtual delivery
Virtual-mailbox domains and aliases:
For many applications the virtual table provides a reasonable 1 to many
list rewriting mechanism that applies to all messages irrespective of the
underlying delivery agent.
This said, the virtual table has some notable limitations:
- At most 1000 expanded recipients per address. Additional
recipients are dropped "silently" (no bounce, just a warning
- No list-owner addresses.
- No :include: files.
- No commands for vacation or other processing, ...
It is sometimes necessary to take advantage of the additional capabilities
of the "local" delivery agent's "alias" and ".forward" mechanisms for
virtual-mailbox addresses. This is handled by rewriting the
virtual-mailbox address to an aliased "local" address that is serviced by
the "local" delivery agent.
To unsubscribe, send mail to majo...@postfix.org with content
(not subject): unsubscribe postfix-users
1.Technically, for an smtp server (which can do a table lookup and locate
domains and users) , what difference it makes if the user is 'local' or
'virtual' as far as mail delivery is concerned.(I mean what is the
difference in 'local' and 'virtual' delivery agent, if the user is local
suid and deliver else deliver to the virtual mailbox).According to me a
e-mail system should be independent of the operating system users.( This is
a pain with other e-mail systems like MSExchange/Groupwise etc, where you
always have to have a system account for the mail to work.Lotus notes allows
you to create e-mail users without having a local user, but who cares).This
may be because of traditional reasons....
2.Why is that vacation/.forward/.filter etc are not available to virtual
users ? (delivery agent never has to write to mail_dir_base or to anyother
file other than mailbox).
What I am coming to is a 'hosting ' model seems to be the future for
everything and postfix seems to be an excellent solution for this (ofcourse
with an equally good IMAP server).
Thanks again for the info.
=== message truncated ===
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
> what difference it makes if the user is 'local' or 'virtual'
Email on UNIX existed prior to SMTP, POP and IMAP. Unix shell users have
traditionally enjoyed a variety of file based access methods to their
mail including .forward files which allow the user to filter mail
through UNIX commands of theier choice, this requires that the user
be allowed to run commands on the machine and so requires a UNIX
shell account. The "local" delivery agent is for shell users, the
"virtual" delivery agent is for POP/IMAP only users.
Postfix supports both "local" and "virtual" users, you decide what you
> 2.Why is that vacation/.forward/.filter etc are not available to virtual
> users ? (delivery agent never has to write to mail_dir_base or to anyother
> file other than mailbox).
Because "virtual" users are not shell users, and cannot specify
arbitrary commands that should run to filter their mail. The functionality
of vacation is not currently available in a smaller language (that can
be processed by a delivery agent) than the UNIX shell.
It is possible to use "local" + mailbox_command_maps + appropriate
management tools, to get a managed menu of mail delivery mechanisms for a
community of users with no shell access, but they need to be listed in the
password file to allow the commands to run in the right security context.
> > 2.Why is that vacation/.forward/.filter etc are not available
> > to virtual users ? (delivery agent never has to write to
> > mail_dir_base or to anyother file other than mailbox).
> Because "virtual" users are not shell users, and cannot specify
> arbitrary commands that should run to filter their mail. The
> functionality of vacation is not currently available in a smaller
> language (that can be processed by a delivery agent) than the UNIX
That's not 100% and entirely true.
I've maintained a vacation written in .procmailrc for a long time,
and it'd be very easy to translate to a .mailfilter for maildrop.
maildrop works very nicely as a virtual delivery agent, in
conjunction with Courior imap/pop.
If you make each user's maildir be their home dir in the virtual
user's database, you can give each one a .mailfilter of their very
own. You can then set up a simple web form for letting them do
whatever you want to allow them to do. Simply enabling and disabling
vacation processing would be easy to allow; so would simple
filtering into folders.
You wouldn't want to allow them to write arbitrary maildrop config
code, only special, carefully limited idioms through a CGI with
careful error checking.
If someone would get around to writing a translater from Sieve
to maildrop, to allow a Sieve web interface to let virtual users
configure filtering in their maildroprc, that'd just about
completely solve this issue.
Oh, it'd be nice if someone would also translate Junkfilter into
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----