Quanah Gibson-Mount: > mydestination = localhost > transport_maps = proxy:ldap:/opt/zimbra/conf/ldap-transport.cf > virtual_alias_domains = proxy:ldap:/opt/zimbra/conf/ldap-vad.cf > virtual_alias_expansion_limit = 10000 > virtual_alias_maps = proxy:ldap:/opt/zimbra/conf/ldap-vam.cf > virtual_mailbox_domains = proxy:ldap:/opt/zimbra/conf/ldap-vmd.cf > virtual_mailbox_maps = proxy:ldap:/opt/zimbra/conf/ldap-vmm.cf > virtual_transport = error
For background, you may want to read up about address classes: http://www.postfix.org/ADDRESS_CLASS_README.html Which address class does zre-ldap002.eng.vmware.com match? - virtual_alias_domains? If this is the address class, valid recipients in this domain must be aliased to a different domain. The remaining recipients are hard-coded to resolve to: transport=error nexthop=User unknown in virtual alias table recipient=localp...@zre-ldap002.eng.vmware.com Yesterday's trivial-rewrite patch changes that into "5.1.1 User unknown...". - virtual_mailbox_domains? If this is the address class, then all known and unknown recipients in this domain will resolve to: transport=error nexthop=zre-ldap002.eng.vmware.com recipient=localp...@zre-ldap002.eng.vmware.com The resolver's result may be mutated further by transport_maps lookups, before the error mailer submits a non-delivery notification. As documented, - The error mailer reports the value of the nexhop attribute as the reason for non-delivery. - If you specify a transport name without nexthop attribute, then the nexthop attribute becomes the recipient's domain. I could speculate that your "virtual_transport = error" causes the nexthop to become the recipient domain (zre-ldap002.eng.vmware.com) which then is reported as the reason for non-delivery, but I don't speculate because I have no idea what your LDAP results are. To find out what really happens you need to answer the questions above and walk through the LDAP lookups. Wietse
