On Fri, Jan 08, 2016 at 03:08:33PM -0800, Quanah Gibson-Mount wrote:
> >I usually solve this differently. I avoid self-referential
> >expansions!
> >
> > virtual:
> > use...@example.com
> > use...@mailstore-name.example.com,
> > use...@mailstore-name.example.com,
>
> Thanks, that makes a lot of sense. We have a concept of an internal home
> mailbox server, so if we modified things to use it inside our ldap map for
> virtual_alias_maps, I think it'd resolve the problem
That's the idea anyway.
> However, I think there is an underlying flaw in our virtual_alias_maps ldap
> mapping:
>
> query_filter =
> (&(|(zimbraMailDeliveryAddress=%s)
> (zimbraMailAlias=%s)
> (zimbraMailCatchAllAddress=%s))
> (zimbraMailStatus=enabled))
> result_attribute = zimbraMailDeliveryAddress,
> zimbraMailForwardingAddress,
> zimbraPrefMailForwardingAddress,
> zimbraMailCatchAllForwardingAddress
>
> Because we include zimbraMailDeliveryAddress as both a search key and a
> result, it will continually get expanded. It'd make more sense then, I
> believe to be something like:
Indeed, in my implementations, the delivery domains are never
virtual, and the ldap tables are configured to not query said
domains:
# Virtual domains for ldap lookup
domain = example.com, ...
with the input mail addresses in the virtual domains subject to
virtual alias expansion, but the (leaf) outputs generally not
landing in those domains. Only when one virtual address is an
alias for another (rather delivers for itself to a mailbox domain)
are the lookups recursive.
This also means that I avoid returning the query attribute, the
multi-valued forwarding address attribute also returns the input
address, when the forward is a Cc, rather than a "redirect".
The simplest version of this is:
domain = example.com
query = (mail=%s)
resultAttribute = maildrop
# Example LDIF:
mail: ju...@example.com
maildrop: ju...@imap.example.com
Everything else is just elaboration on the theme, with
special_result_attribute indirection, leaf and terminal attributes,
... I used the lot at Morgan Stanley, where I developed those
features because I needed them.
--
Viktor.
