User Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0 Build ID: 20111026191032 Steps to reproduce: LDAP failed to connect as I upgraded to version 10.0

Wisspur can you find the regression date using http://www.rumblingedge.com/2009/02/24/howto-find-regression-windows-through-manual-binary-search/ ? What exact message do you get when it fails ? Can you log what's happening as described at https://wiki.mozilla.org/MailNews:Logging and attach the log on the bug ?

Have been using the same Directory Server Properties for all Thunderbird versions. It only works in version 8, and failed in both version 9 and 10. It used to work in version 9, until the recent update (11/8/2011). When running the offline replication, the message indicates that the replication process is failed. Same thing when you conmpose a new message, and it can't connect to the LDAP Server and retrieve the address.

wisspur, do you still see this issue if you use newer build - trunk, aurora or beta? if you do, can you find regression using nightly/daily builds?

This issue remains, no matter what version (trunk, aurora or beta) I used. The latest version I've tried was 13.00a1 from http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/ The best Thunderbird version that was working well for me with Kerio Connect 7.3.2 is 9.0.1 :-(

Rough regression window by posted comments. Good : Tb 8, Tb 9.0.1, Tb 9 before update on 2011/11/08 Bad : Tb 9 after update on 2011/11/08, Tb 10, Tb 13.00a1 May be similar issue to Bug 723109 if SSL is used(problem of Bug 702111 in SSL after fix of bug 665814.) Can you get LDAP log? (see bug 402793 comment #28 for getting protocol log) Is your LDAP server accessed via SSL? If SSL is used, try setting NSS_SSL_CBC_RANDOM_IV=0 in your environment variable(see bug 723109 comment #22.)

LDAP log (TB version 13.00a1) ----------------------------------------------------------------------------- 2012-03-10 05:06:50.515000 UTC - 0[200f140]: nsLDAPOperation::SimpleBind(): called; bindName = 'user@domain.com'; 2012-03-10 05:06:50.578000 UTC - 0[200f140]: pending operation added; total pending operations now = 1 2012-03-10 05:06:58.531000 UTC - 0[200f140]: nsLDAPConnection::RemovePendingOperation(): operation removed 2012-03-10 05:06:58.531000 UTC - 0[200f140]: nsLDAPConnection::RemovePendingOperation(): operation removed; total pending operations now = 0 2012-03-10 05:06:58.531000 UTC - 0[200f140]: unbinding 2012-03-10 05:06:58.531000 UTC - 0[200f140]: unbound ------------------------------------------------------------------ Yes, the LDAP server is accessed via SSL. TB 13.00a1 will work with setting NSS_SSL_CBC_RANDOM_IV=0, but I think that will defeat the security purpose.

(In reply to wisspur from comment #6) > Yes, the LDAP server is accessed via SSL. > TB 13.00a1 will work with setting NSS_SSL_CBC_RANDOM_IV=0, > but I think that will defeat the security purpose. (i) NSS_SSL_CBC_RANDOM_IV=0 is to bypass bug of your LDAP server when change by bug 665814 for CVE-2011-3389 is applied to Tb. (ii) If Tb is started from BAT, NSS_SSL_CBC_RANDOM_IV=0 is used only for Tb and other applications are not affected. TB.BAT SET NSS_SSL_CBC_RANDOM_IV=0 " ...\thunderbird.exe" -P "prof_name" ... (iii) If NSS_SSL_CBC_RANDOM_IV=0 is used for Tb, securiy risk of CVE-2011-3389 is not removed for other Tb's servers accesses via SSL. (iv) securiyu risk of CVE-2011-3389 currently exist actually in many applications including Tb and many servers. (a) "securiyu risk of CVE-2011-3389 in other server access by Tb" (b) "failed LDAP server access due to solution of CVE-2011-3389 by bug 665814" If (a), which currently does exist, is far important than (b) for you, don't use the "bypass of your LDAP server's bug by NSS_SSL_CBC_RANDOM_IV=0". If (a), which currently does exist, is acceptable until bug of your LDAP server will be fixed, and if (b) is very important problem for you, use the "bypass of your LDAP server's bug by NSS_SSL_CBC_RANDOM_IV=0" until bug of your LDAP server will be fixed. To use bypass of NSS_SSL_CBC_RANDOM_IV=0 for LDAP access, or not to use bypass of NSS_SSL_CBC_RANDOM_IV=0 for secutity risk, is up to you.

Thank you for the info. I've decided to stay with TB 9.0.1 since it's working extremely well for me. I'll wait for Kerio to fix the LDAP bug to accomodate the changes Mozilla (CVE-2011-3389) made to TB 10.00 and 13.00a1, then I'll switch. The only wish I've for TB is the capability to automatically resize, to fit, the in-line bitmaps in preview windows (it does resize the the attached bitmaps, however, but not in-line).

A question I forgot to ask. Has Mozilla informed Kerio about this LDAP bug?

(In reply to wisspur from comment #9) > A question I forgot to ask. Has Mozilla informed Kerio about this LDAP bug? We have notified them about the SLL issue (it also affects imap and smtp). But getting it from their customers helps too.