Quanah Gibson-Mount:
> I changed the value for virtual_transport to be:
>
> error: 5.1.1 Mailbox unavailable
>
> And now I see:
>
> Oct 2 11:54:21 zre-ldap002 postfix/error[331]: 897561E37C6:
> to=<zim...@zre-ldap002.eng.vmware.com>, relay=none, delay=0.06,
> delays=0.03/0/0/0.02, dsn=5.1.1, status=bounced (Mailbox unavail
> able)
> Oct 2 11:54:21 zre-ldap002 postfix/qmgr[327]: 897561E37C6: removed
>
> So, does that look more correct to you as the way to correctly handle this?
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.
This would be a good time to study ADDRESS_CLASS_README. I have
mentioned this document before.
Wietse
