--On Tuesday, October 02, 2012 8:11 PM +0000 Viktor Dukhovni
<postfix-us...@dukhovni.org> wrote:
On Tue, Oct 02, 2012 at 03:34:38PM -0400, Wietse Venema wrote:
Alas, it makes no sense to me, and I am the person who designed
this mail system.
In particular I fail to understand what this is meant to achieve:
1) list the domain in virtual_mailbox_domains.
2) set the delivery agent to "error".
I suspect that this is combined with virtual aliases or transport
maps to redirect "good" recipients away from the error transport,
towards a proper delivery agent.
This is working against the system, and therefore I anticipate more
trouble down the road.
Proper usage of the Postfix virtual mailbox address class is:
1) list the domain(s) in virtual_mailbox_domains.
2) list the valid recipients in virtual_mailbox_maps
3) configure a proper delivery agent with virtual_transport
With this, Postfix takes care of non-existent recipients. There
is no need for manual "error" delivery agent configuration, or
for word-smithing the "user unknown" error message.
Similar usage is recommended for the other Postfix address classes:
the virtual alias class (which has no delivery agent), the relay
class with relay_transport, and the local address class with
local_transport.
Indeed I was only responding to the question of how to get error(8)
to generate a sensible DSN status code and error message. Whether
it is wise to route the mail in question to the error transport
via "virtual_transport=error:5.1.1 <text>" is a separate issue
I did not address.
Indeed it is typically best to not fight the system, and let Postfix
determine valid recipients in the standard way.
There be some existing logic in smtpd(8), that rejects all recipients
that explicitly resolve to the error transport. In which case in
combination with an LDAP-based per-user transport table, something
sensible may happen for this domain. If so it is a rather complicated
design, perhaps it can be made more "natural".
Thanks again! I will see if I can figure out what the intent was to begin
with, and rework this into a more reasonable configuration.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
