> On Sep 19, 2019, at 2:37 PM, Bill Cole
> <postfixlists-070...@billmail.scconsult.com> wrote:
>
>> server_host = ldap://zimbraldap:389
>> server_port = 389
>> search_base =
>> query_filter =
>> (&(|(zimbraMailDeliveryAddress=%s)(zimbraMailAlias=%s))(zimbraMailStatus=enabled))
>> result_attribute = mail,zimbraMailAlias
>
> See the ldap_table(5) man page:
>
> After applying the result format, multiple values
> are concatenated as comma separated strings.
>
> If your records can contain both mail and zimbraMailAlias attributes (or may
> contain multiples of either,) see the documentation of "expansion_limit" in
> the same man page. If they all contain both attributes, pick one.
Yes, the LDAP table result for transport resolution must be "single-valued",
and a comma-separated list is unlikely to work. That said, one might
hypothetically be able to chain the LDAP reply with some sort of PCRE-based
table via "pipemap", to extract a single transport value. I'd advise against
that, and base the transport result on a single LDAP attribute. If it needs
some post-processing to give an answer in the correct format, then consider
"pipemap".
ldap = proxy:ldap:${config_directory}/
pcre = pcre:{$config_directory}/
transport_maps = pipemap:{
${ldap}ldap-transport.cf,
${pcre}ldap-transport.pcre
}
The PCRE table can do simple substitutions, perhaps
/(.*)/ relay:[$1]
if, e.g., the user's mailstore host is returned from LDAP as just
the hostname.
That said, I actually strongly discourage LDAP/SQL-based transport
tables. Transport lookups are done sequentially in the queue
manager, and any interruption in service severely disrupts all
mail delivery, and lookup latency hampers performance.
My advice is to do virtual alias rewriting, and then resolve
to a transport on just the domain part of the address via
local indexed files. If necessary, the rewriting can be
reversed in smtp_generic_maps for delivery to the mailstore
in the original primary public address form.
--
Viktor.
