Hello, I'm a developer on the Exim MTA and I have some questions about differing behavior I am seeing across different systems. I would like some suggestions about the best way to handle each issue. First, I have not gotten "a ton of complaints." One person contacted me with the issues I am describing below. I do not know his server or client versions, other than his workstation is Debian Squeeze. I'll just refer to him as "the guy". Second, my test server is running openldap 2.3.34, my workstation on which I am running my test builds of Exim is using openldap 2.4.28 client libs. Issues: 1. When multiple servers are specified, our ldap code just did an unbind to all servers defined when it was finished. The guy contacted me with the problem that the unbind call hangs when one of the ldap servers was unavailable for whatever reason. On *my* system, the blind unbind worked properly no matter if the bind succeeded. I modified the ldap code so that it only unbinds if the original bind succeeded. That seems the proper/correct way to handle it in all cases, so this issue really is already solved. I'm just wondering if there are any gotchas I might be missing by doing it this way. 2. A few months ago I helped (a different) someone troubleshoot a really strange problem where setting the LDAP_OPT_X_TLS_REQUIRE_CERT option in our code did not have any impact on his machine. Our code set that option per connection. It turns out that, for him, setting that option per connection did not affect the TLS require cert option that the bind used. He found some comment somewhere advising that NULL for the ldap handle sets the option globally in the ldap client. We tried it and it solved the problem for him. I saw identical behavior on my system (NULL worked, ldap handle did not) so we assumed that the code had never really worked properly. I then changed our ldap code to use NULL instead of the ldap handle when setting the TLS require cert option. The guy (with the current problem) runs a system that worked just fine previously, but using the new code (NULL instead of ldap handle when setting TLS require cert option) does not affect the TLS require certificate setting when his bind is attempted. After much testing and debugging, I had him merely change that one line back to using the ldap handle in ldap_set_option() and it then worked properly for him. So I have two systems (mine and his) which behave differently after the ldap_set_option() on LDAP_OPT_X_TLS_REQUIRE_CERT. In a fit of psychotic testing, I decided on my system to just blindly set it both globally and per connection. It worked, and produced no errors. That surprised me, I expected one or the other to complain. My potential code looks like the following (apologize if Gmail wraps), can you explain any pitfalls of doing it this way? Should the two be #ifdef guarded by client lib version checks or something? /* Use NULL ldap handle b/c is global in some client libs */ rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert_option); if (rc) { DEBUG(D_lookup) debug_printf("Unable to set TLS require cert_option(%d) globally: %s\n", cert_option, ldap_err2string(rc)); } /* Use current ldap handle b/c is per-connection in others */ rc = ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert_option); if (rc) { DEBUG(D_lookup) debug_printf("Unable to set TLS require cert_option(%d) on LDAP server " "%s%s: %s\n", cert_option, host, porttext, ldap_err2string(rc)); } Any comments or suggestions are appreciated. ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine