ldap lookups timing out?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ldap lookups timing out?

Gomes, Rich

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: [hidden email]: search aborted

 

 

I can’t find an exact solution for this in my searches. I realize that a 400 level error would be re-tried but the issue is a lot of internal apps here are not “SMTP-compliant”.

 

Is there a timeout I can adjust or a way to cache previous searches?

 

The only workaround I can offer the application owners is to route their mail to localhost and use the localhosts SmartHost setting to route it to the preferred relay. This way localhost can handle the retries since the application quits on anything other than a 200-level error.

 

 

 

Thanks,

Rich

 

 

 

 

 

 

 

 

 

Rich Gomes | Aramark | Senior Systems Administrator | Messaging and Collaboration Services

141 Longwater Drive

Norwell, MA  02061

P: 1 (781) 763-4508

 

Reply | Threaded
Open this post in threaded view
|

Re: ldap lookups timing out?

Coy Hile
On 2019-08-22 13:19, 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: [hidden email]: search aborted
>
> I can't find an exact solution for this in my searches. I realize that
> a 400 level error would be re-tried but the issue is a lot of internal
> apps here are not "SMTP-compliant".
>
> Is there a timeout I can adjust or a way to cache previous searches?
>
> The only workaround I can offer the application owners is to route
> their mail to localhost and use the localhosts SmartHost setting to
> route it to the preferred relay. This way localhost can handle the
> retries since the application quits on anything other than a 200-level
> error.
>

Hitting LDAP that much seems like a poor design, as it becomes expensive
(and has the other downsides you mentioned). If you must use LDAP, does
whatever you're using cache results locally so that it only hits the
network when it must (similar to what ones does with nss lookups via
nscd and friends?)

--
Coy Hile
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ldap lookups timing out?

Viktor Dukhovni
In reply to this post by Gomes, Rich
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: [hidden email]: search aborted

This is much too little information about your system:

        http://www.postfix.org/DEBUG_README.html#mail

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:
        [hidden email] relay:mailstore1.example.com
        [hidden email] relay:mailstore2.example.com
        ...

I use:

    virtual:
        [hidden email] [hidden email]
        [hidden email] [hidden email]
        ...

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:
        [hidden email] [hidden email]

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

RE: ldap lookups timing out?

Gomes, Rich
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: [hidden email] <[hidden email]> On Behalf Of Viktor Dukhovni
Sent: Thursday, August 22, 2019 7:10 PM
To: [hidden email]
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: [hidden email]: 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:
        [hidden email]       relay:mailstore1.example.com
        [hidden email]       relay:mailstore2.example.com
        ...

I use:

    virtual:
        [hidden email]       [hidden email]
        [hidden email]       [hidden email]
        ...

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:
        [hidden email]    [hidden email]

--
        Viktor.