Some end users in the environment are not able to be successfully validated as a good recipient. To verify this follow these steps: 1. Login to the Symantec Messaging Gateway (SMG) Brightmail Control Center (BCC) 2. Click on Administration->Settings->Directory Integration 3. Click on the name of the LDAP server where the end user's mail address is stored. 4. Click on the Recipient Validation Tab 5. Enter in the email address of the affected user and press Test Query 6. Seeing an error message of "The test address was not found in the directory (invalid recipient)." indicates this condition.
In the DDS log shows the following error "[LDAP: error code 32 - No Such Object]" when the BCC is used to Validate the affected user in the prior steps.
When the DDS log is set to DEBUG logging levels, the log shows that the affected user is located however, the second query to load the user's attribute fail. For example the following shows a initial lookup for firstname.lastname@example.org which succeeds:
In the second query for the user in the DDS log we can see the LDAP query fail for this user:
... Jul 24 2012 19:40:24 [btpool0-1] [EntryDAOSpringLdap] DEBUG - [Lotus Domino LDAP 01] fetching Recipient or Group getGenericByUniqueId() for cn=affected user,ou=corp,ou=US,o=OrganizationName Jul 24 2012 19:40:24 [btpool0-1] [FastSyncKeyedObjectPool] DEBUG - [Lotus Domino LDAP 01] fetched idle connection from pool Jul 24 2012 19:40:24 [btpool0-1] [DDSDirContextValidator] DEBUG - [Lotus Domino LDAP 01] DirContext validation succeeded Jul 24 2012 19:40:26 [btpool0-1] [FastSyncKeyedObjectPool] DEBUG - [Lotus Domino LDAP 01] returning connection to idle pool Jul 24 2012 19:40:26 [btpool0-1] [EntryDAOSpringLdap] DEBUG - [Lotus Domino LDAP 01] couldn't resolve entry for: cn=affected user,ou=corp,ou=US,o=OrganizationName Jul 24 2012 19:40:26 [btpool0-1] [EntryDAOSpringLdap] DEBUG - [Lotus Domino LDAP 01] (this is expected when the lookup is a result of membership building and there is more than one address resolution source) org.springframework.ldap.NameNotFoundException: [LDAP: error code 32 - No Such Object]; nested exception is javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'cn=affected user,ou=corp,ou=US,o=OrganizationName' at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:172) ...
There are other users in the environment that recipient validation succeeds as expected for.
There are failing users and the succeeding users that are within the same LDAP OU structure.
There is an underlying issue with the account that is being access by SMG. The LDAP server is responding back to SMG that the expected account object is not present.
Contact your local LDAP admin to help troubleshoot the issue. Specifically the LDAP admins should be given examples of LDAPsearch queries for a working user and one for a failing user for comparison. See the additional information section for the recommended set of data to provide.
The ldapsearch tool which comes installed on SMG can be used to help verify this issue. By using the same queries that SMG uses, the ldapsearch tool can help verify where the issue is coming from.
For example, from the above DDS logs from SMG, we can create the same initial query in the ldapsearch too, here <login> is the account used by SMG to access the LDAP server:
The above query is expected to fail for this issue with the Error code 32 message.
These queries should be used for two users, a working user and a user where the recipient validation fails. For a working user the OU and O paths should be the same as the affected user to make troubleshooting the affected user as easy as possible.
For example, the queries for a working user would be similar to the following and would both succeed without errors: