cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3540
Views
0
Helpful
5
Replies

Problem response query LDAP vs server Lotus/Domino

arnaudbesnard
Level 1
Level 1

Hi,

I have some problem with the query LDAP accept. My LDAP server is a Lotus server and I activate the query LDAP accept on my public listener.
Several times I have the message in the LDAP debug: Critical: LDAP: query LDAP.accept result Query timed out.
In the mail-log, I have the message: 451 Temporary recipient validation errors.I lost several messages.
I observed that the good query LDAP response in less 5 second and the others response between 6 seconds and 45 seconds or more.
I know the solution of my problem is my LDAP server but can I have other solutions to upgrade my hardware on my server? The performances on this server are deteriorated.

Can I increase the values of response on Ironport for the queries LDAP. Or do you have a other solutions. If not I will have to disable the LDAP accept on my listener, it’s problematic.

Tks for you help

5 Replies 5

Erich_ironport
Level 1
Level 1

Significantly increasing the LDAP cache size and timeout on the IronPort may help by reducing the load on your LDAP server.

ldapconfig -> edit -> {pick a server config} -> server -> cache -> (set TTL to 43,200 seconds (12 hours), max cache entries to something > total number of valid email addresses).

I know this command is in earlier versions, but the local may be slightly different from above (I'm referencing a version 5.5 beta host)

Hope this helps.

The only side effect is a few invalid messages to your backend mail servers for 12 hours after to remove an email address from LDAP.

Erich

Doc_ironport
Level 1
Level 1

A 451 response shouldn't lose the message - it should cause the sending server to re-try again later.

I'm not aware of a way to change the timeout, but you certainly can control what happens when the lookup fails.

In the Listener configuration under "LDAP Queries" -> "Accept" there a setting to control what happens when the LDAP query fails, which you can change to "Allow Mail in".

This will mean that some mail to invalid addresses may make it through to your mail server, but that may be a better option that returning temporary failures.

Abes,

When I implement LDAP acceptance at customer sites I crank up the values for both LDAP Cache entries and TTL (Cache Time To Live). My typical rule of thumb is 10x the user cound for Cache entries and 1 day for the TTL.

So if you have 2000 users I change the Cache entries from 10,000 to 20,000. I do this for two reason, 1. the IronPort caches both positive and negative LDAP results, 2. most users have multiple e-mail addresses/aliases.

With regards to the Cache TTL by default it's set to 15 minutes which in my opinion might be two aggressive consider the low chance of a "false positive". Basically the only chance of a 1 day TTL causing a problems is if a spammer attempted to send mail to joe.blow@example.com (which didn't exist at the time) and then the organization hired (or created an alias) Joe Blow. At this point the e-mail address is cached as a cache negative response and the new user wouldn't get mail for up to 24 hours. The chances of this are pretty remote.

This should take the load off the LDAP servers, typically my customers don't even see a performance hit on the LDAP environment with these guidelines.

And as Doc stated you shouldn't "lose" mail with a 451 error, just delay the delivery to the desired end user.

Sincerely,

Jay Bivens
IronPort Systems

Rayman_Jr
Level 1
Level 1

There are two important settings on the Domino side which might be good to check.

1. Make sure your LDAP directory is full text indexed (this is very important to get better respond times)
2. Verify that 'compact' task doesn't lock down the directory. For example copy style or in-place with file size reduction will lock down the directory from LDAP lookups. I'm using 'compact -b' without problems

Hello,

We've started receiving an enormous amount (a few hundred per day) of the following LDAP messages:

"LDAP group query failure during per-recipient scanning, possible LDAP misconfiguration or unreachable server"

When we look at our LDAP server, the response times look okay. On the IronPort side, we are currently set to 30,000 cache entries and a TTL of 36,000 sec. We have approximately 28-30,000 e-mail users.

Our queries haven't changed in quite a while. We upgraded to 5.1.1 approximately a week after these errors started, so we ruled that out as a cause of/help for the problem. Do you see upping our cache entries/TTL numbers helping with this error, as suggested for the other LDAP error? If not, do you have any other suggestions? Thanks.

Tony

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: