This is the line from main.cfg:
relay_recipient_maps = hash:/etc/postfix/wildcard_relay_recipients,
proxy:ldap:/etc/postfix/ldap_relay_recipients.cf,
proxy:ldap:/etc/postfix/ldap_groups_recipients.cf
I am unclear on the transport maps section of your response. I am using
transport maps but they look like this:
mydomain.com smtp:[myexchangeserver.mydomain.com]:25252
myotherinternaldomain.com smtp:[This goes to a
differentexchangeserver.mydomain.com]:25252
myotherotherinternaldomain.com
smtp:[thisgoestoaninternalfaxserver.mydomain.com]:25252
etc....
-----Original Message-----
From: owner-postfix-us...@postfix.org <owner-postfix-us...@postfix.org> On
Behalf Of Viktor Dukhovni
Sent: Thursday, August 22, 2019 7:10 PM
To: postfix-users@postfix.org
Subject: Re: ldap lookups timing out?
CAUTION: This email was sent from an external sender. Do not click links or
open attachments unless you recognize the sender and know the content is safe.
On Thu, Aug 22, 2019 at 05:19:37PM +0000, Gomes, Rich wrote:
> I am seeing a lot of Temporary lookup failure errors in the maillog.
> At first I thought it was an issue related to reverse DNS lookups as
> each of the sending servers had no reverse record in DNS (this is an
> internal only relay).
> But when I added verbose logging, it appears to be related to LDAP lookups.
>
> Most commonly, I get these errors:
>
> warning: dict_ldap_connect: Unable to bind to server ldap:....
>
> But also receive these:
>
> maps_find: relay_recipient_maps: u...@mydomain.com: search aborted
This is much too little information about your system:
https://clicktime.symantec.com/36xM5GtzzWZLWjZscKcRTZH7Vc?u=http%3A%2F%2Fwww.postfix.org%2FDEBUG_README.html%23mail
Perhaps you're using "ldap:table", rather than "proxy:ldap:table".
You'll likely do much better with:
ldap = proxy:ldap:${config_directory}/
relay_recipient_maps = ${ldap}relay-rcpt
...
Make sure your LDAP tables are sensibly indexed, so that the queries you're
making are efficieint and do not involve full table scans.
You don't need to avoid or cache LDAP, per other suggestions, but I do try to
not use LDAP for "transport_maps" on high-volume relays.
This is because the queue manager is single-threaded, and does transport
resolution (via trivial-rewrite(8)) for every message recipient as messages
enter the active queue.
Therefore, instead of:
transport:
us...@example.com relay:mailstore1.example.com
us...@example.com relay:mailstore2.example.com
...
I use:
virtual:
us...@example.com us...@mailstore1.example.com
us...@example.com us...@mailstore2.example.com
...
and configure the mailstore SMTP/LMTP servers to accept the rewritten address
form. If push comes to shove, you can also rewrite the address back to the
input form during onward delivery:
master.cf:
relay unix ... smtp
-o smtp_generic_maps=$relay_generic_maps
main.cf:
smtp_generic_maps = <table_type>:generic
generic:
us...@mailstore1.example.com us...@example.com
--
Viktor.
