Reproduction: 1. A POP3 server which uses "GSSAPI" (Kerberos) as possible authentication mechanism (be it spurious or not, see below). 2. Enable "secure auth" in prefs for that server. 3. Connect to the server, by clicking on Actual result: The UI blocks for the time we make the Kerberos network connection. Expected result: Never block the UI thread on network connections. Kerberos advertised, but not used: Some servers have the necessary libs installed, but not set up (keytab etc.), and wrongly advertise GSSAPI. See <https://wiki.mozilla.org/MailServerList#Secure_Auth> for how to find advertising GSSAPI. I don't know what the gssapi lib then does. From my own tests when I had Kerberos not set up yet, not adjusted /etc/krb5.conf yet, I noticed a several-second hang when trying to get an initial Ticket-Granting-Ticket (TGT), so it seems that the code still tries to find a Kerberos server, and fails, and that takes a few seconds. If that's true, it would increase severity of this bug, because many more users would see this bug, and probably worse than Kerberos users. Big ISPs normallly don't advertise GSSAPI, but smaller, badly administered servers may. We may (or may not) be able detect that situation, and could avoid a network connection in this case, and that would help for users who don't use Kerberos, but it would not fix this bug, because it doesn't help users who do use Kerberos. Code: http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsPop3Protocol.cpp#1694 http://mxr.mozilla.org/comm-central/source/mozilla/extensions/auth/nsAuthGSSAPI.cpp http://mxr.mozilla.org/comm-central/source/mailnews/base/util/nsMsgProtocol.cpp#835 DoGSSAPIStep1/2() calls authModule->GetNextToken(), which calls gss_init_sec_context(). The latter goes to the Kerberos server. <http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/GSSAPIPG/p12.html> The IMAP implementation is not affected, because it does not run on the UI thread, but in its own. I don't know about SMTP.