In the test script for latency below, does table/file.cf refer to the
ldapconfig file I am using?
$ domain=example.com # Replace with actual domain
$ i=0; while (( i < 1024 )); do
echo "$i-probe@$domain"
i=$(( i + 1 ))
done | time postmap -q - ldap:/table/file.cf
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Gomes, Rich
Sent: Friday, February 10, 2017 2:49 PM
To: Postfix users <[email protected]>
Subject: RE: dict_ldap_lookup questions
I am using ldap:
I will try using it as proxy:ldap: instead as well as your script suggestion
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Viktor Dukhovni
Sent: Friday, February 10, 2017 2:43 PM
To: Postfix users <[email protected]>
Subject: Re: dict_ldap_lookup questions
> On Feb 10, 2017, at 2:27 PM, Gomes, Rich <[email protected]> wrote:
>
> The reason the query is setup like that is we have several internal
> domains and a user may have an alias for one or all of them depending
> on their employment history.
You've failed to understand my response. The "proxyAddresses" attribute is
multi-valued, and returns results of the form "smtp:<rfc822address>".
Nothing in Postfix can uses such results, so you're better off returning a
single-valued attribute such as "mail".
> Since it is working as expected, I'd rather leave it as is, unless you
> feel it may be a contributor to the issue I am seeing.
The primary recommendation is to use "proxy:ldap:" rather than "ldap:".
You've not yet explained what you're using LDAP for. Is this a
relay_recipient_maps table? Some other table that ignores the RHS value?
Have you tested lookup latency with:
$ domain=example.com # Replace with actual domain
$ i=0; while (( i < 1024 )); do
echo "$i-probe@$domain"
i=$(( i + 1 ))
done | time postmap -q - ldap:/table/file.cf
The idea is to establish a single connection and then test ~1000 queries for
distinct addresses (for a domain that matches the domain= constraints in the
table definition). The actual addresses need not exist in LDAP.
Report your results.
--
Viktor.
