Version: 1.9.1 (using KDE 3.5.1, Debian Package 4:3.5.1-2 (testing/unstable))
Compiler: Target: i486-linux-gnu
OS: Linux (i686) release 220.127.116.11-scyw00225
My Exchange Gurus have reconfigured their servers to require other authentication methods when connecting to it via IMAP. They cannot tell me which methods are supported now.
When I select an authentication method that is not supported, kmail quickly iterates between "The authentication method ... is not supported by the server" and the Authorization Dialog requesting user name and password. it seems impossible to get to a configuration dialog without killing off the Kmail process.
The persistence of Kmail trying to reauthenticate with a method that it knows about being unsupported is a major annoyance.
I have the same problem, after I upgraded to KDE 3.5.1. In my case, the server didn't change but KMail doesn't support the same authentication protocol as before. Trying to kill KMail resulted in a zombie process (?!?) It's extremely annoying behaviour.
Eventually I had to remove the [Account ##] entries from the kmailrc file and add them again manually.
*** Bug 122733 has been marked as a duplicate of this bug. ***
using imap, I get "TLS-Start fehlgeschlagen" (eventually because the account has not been setup correctly). Now Kmail asks again for username and password. Hitting OK or Cancel won't break out of this loop.
KDE/Kmail 3.5.2 gentoo build
*** Bug 126676 has been marked as a duplicate of this bug. ***
*** Bug 127286 has been marked as a duplicate of this bug. ***
same problem here on 3.5.2/SuSE build: cancelation of the login dialog does not break the loop. Impossible to work with Kmail!
A similar loop appears when the IMAP server is down.
*** Bug 122149 has been marked as a duplicate of this bug. ***
*** Bug 130052 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
The same problem happens when the authentication method and protocol and everything is supported but the server simply rejects your username-password combination.
I must agree that this is a major annoyance.
*** Bug 133843 has been marked as a duplicate of this bug. ***
oh damn. turns out, this is a long standing problem...
kmail tries to authenticate upon startup for me, so i can not even get to the configuration.
so, here's a workaround (in 3.5.4) :
open kontact, not kmail. cancel login dialog once, open settings. now, reconfigure your account details (kmail does not allow accessing settings while the dialog window is open).
*** Bug 135507 has been marked as a duplicate of this bug. ***
This bug report is the same as http://bugs.kde.org/show_bug.cgi?id=109036.
It's just that this one is about wrong authentication method, and that one is about wrong password. But the problem as such is the same, "Cancel" doesn't cancel.
109036 might be considered a duplicate.
Additionally, this is a regression of http://bugs.kde.org/show_bug.cgi?id=93199.
*** This bug has been marked as a duplicate of 109036 ***
Same loop here kmail 1.9.6, kde 3.5.6 gentoo. Workaround from comment 13 helped me out.
I have kdepim-3.5.6-4.fc7 and similar bug exists in my KMail. When configuring IMAP mailbox on first start through wizard, by default program selected PLAIN authentication method, and on finish i have this endless loop because this method is unsupported by server.
I might have had this problem today [KMail/1.9.6 (enterprise 0.20070907.709405), Kubuntu 7.10].
When starting either Kontact or KMail, there was an error message about my Google Mail account which I access with IMAP:
Authorization failed, Unable to login. Probably the password is wrong.
The server imap.googlemail.com replied:
System Error (Failure) authentication not supported
Clicking OK (the only option in this box) brought up a dialog asking for username and password. I then entered my password (I'm pretty sure it was correct) and clicked OK, but this only made the "Authorization failed" box appear again. I repeated this a few times without success and finally decided to click "Cancel". This caused KMail/Kontact to hang and use 100% of the CPU (reproducibly), so I had to kill it manually. I managed to get a few backtraces by sending the process the SIGSEV signal, I could attach one if anyone thinks it's useful.
After some time, the problem disappeared. I guess it was a temporary problem with the mail server, but I think KMail should give the user some way to get out of this "Authorization failed" thing (e.g., if he wants to check some other mail accounts that still work).
If this bug is the same thing that I experienced, it is not a duplicate of bug 109036 (in this bug, the dialog box pops up over and over again, but KMail does not hang).
Concerning my comment #19:
I found a way to reproduce this (KMail/Kontact hangs using 100% CPU) even if the IMAP server works all right, but only with the version KMail/1.9.6 (enterprise 0.20070907.709405) that comes with Kubuntu 7.10. The current SVN version (revision 796375) seems to work OK.
Steps to reproduce:
1. Open KMail settings and change the password of a receiving IMAP account (Google Mail in my case) to something wrong. Close the settings dialog. KMail then tries to check mail using the wrong password, opens an Error dialog (click OK) and an Authorization dialog (click Cancel). Close Kontact.
2. Open Kontact. You get an error message about the failed Authorization. Click OK and then Cancel in the Authorization Dialog.
3. Kontact hangs and has to be killed manually.
But as I said, the current SVN version works OK. When I open Kontact and click Cancel in the Authorization dialog prompting me for the correct password, I get the same dialog once more, but clicking Cancel again ends this, and I can use Kontact normally (except for the account with the wrong password).