POP3 auth blocks UI thread on network when attempting Kerberos



MailNews Core
Networking: POP
8 years ago
8 years ago


(Reporter: BenB, Unassigned)


Firefox Tracking Flags

(Not tracked)




8 years ago
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.


DoGSSAPIStep1/2() calls authModule->GetNextToken(), which calls gss_init_sec_context(). The latter goes to the Kerberos server.

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.
You need to log in before you can comment on or make changes to this bug.