Version: 4.6 (using KDE 4.5.85) OS: Linux For the last 4 years I had configured my business linux system to connect (via POP3) to the corporate M$ Exchange Server for retrieving my emails. This procedure worked almost without any problems. That is, until the last update of my system (from KDE 4.6 beta 1 to KDE 4.6 beta 2), when Kmail could no longer connect with the M$ Exchange Server Instance. I can personally verify that _nothing_ has changed on behalf of the Exchange Server (furthermore, I can assure you that using a different application, Thunderbird, I can still connect using the same settings and credentials with the very M$ Exchange Server instance). However, when I attempt to start Kmail (either via Kontanct or alone), I am constantly asked for the user's password, which even if provided correctly, leads to the application complaining that it cannot succeed in connecting with the Exchange Server. The above behaviour leads me to suspect that something has changed (code-wise) between KDE 4.6 beta 1 and KDE 4.6 beta 2 as far as akonadi is concerned (especially with the POP3 implementation part). Reproducible: Always Steps to Reproduce: Simply upgrading from kde 4.6 beta 1 to kde 4.6 beta 2 leads to the reported issue Actual Results: Cannot connect to M$ Exchange Server via POP3 any more Expected Results: Prior to upgrading to kde 4.6 beta 2 from kde 4.6 beta 1, connecting to the M$ Exchange Server via POP3 was feasible As mentioned above, it is quite possible that something has changed (code-wise) between KDE 4.6 beta 1 and KDE 4.6 beta 2 as far as akonadi is concerned (especially with regard to the POP3 implementation part).
After further investigation and googling around, I found a _workaround_ of the reported issue: It appears that a modification concerning the authentication mechanism (that is related with KWallet) resulted to the problem: Once I deleted the respective Akonadi resource and recreated it (using the exact values and credentials), the problem seized to exist. But, as far as I am concerned, such a requirement (to delete and recreate the respective POP3 Akonadi resource) to rectify the issue, should _not_ be an acceptable solution... The following comment might be out of topic, but it's worth reporting: Furthermore, I would like to mention the fact that, in the event of connecting with a server whose certificate is not valid/safe (The Akonadi resourse generates a warning that the server failed the authenticity check), leads to the user taking the responsibility upon herself whether to accept the certificate (either for the current session, or forever), or decline it altogether... If the user chooses to accept the provided certificate _forever_, the akonadi resource will periodically (each and every time it is invoked that is) keep on complaining about the very same certificate issue, thus, _ignoring_ the specific user request for the system to accept the (less safe) certificate!
Thanks for your report. Do you have any way to reproduce your authentication/wallet problem? i.e. are you able to get your current POP3 resource into a state in which that problem happens? If so, please post steps to reproduce. Also, console output from Akonadi can be helpful in this case. To get output, quit Kontact/KMail, go to a terminal to stop Akonadi by typing "akonadictl stop". Then start Akonadi on the console with "akonadictl start" and start KMail and trigger a mail check. You should now see output related to the POP3 resource on the console.
(In reply to comment #2) > Thanks for your report. > Do you have any way to reproduce your authentication/wallet problem? i.e. are > you able to get your current POP3 resource into a state in which that problem > happens? > > If so, please post steps to reproduce. > Also, console output from Akonadi can be helpful in this case. To get output, > quit Kontact/KMail, go to a terminal to stop Akonadi by typing "akonadictl > stop". Then start Akonadi on the console with "akonadictl start" and start > KMail and trigger a mail check. You should now see output related to the POP3 > resource on the console. I would, first of all, like to deeply thank you for your concern! I can certainly provide you with the following akonadi output when kontact/kmail checks for email (but I am afraid it won't be rather useful). When I press the button to check the emails of the pop3 account whose certificate is found to be weak, nothing is produced at the Akonadi output, until I explicitly request to accept that very certificate forever. Then, akonadi produces the following output: akonadi_pop3_resource_2(18205)/kio (KIOJob) KIO::TransferJob::slotData: mimeType() not emitted when sending first data!; job URL = KUrl("pop3://nassos%40kourentas.com@mail.kourentas.com:110/index") data size = 0 akonadi_pop3_resource_2(18205)/kio (KIOJob) KIO::TransferJob::slotData: mimeType() not emitted when sending first data!; job URL = KUrl("pop3://nassos%40kourentas.com@mail.kourentas.com:110/uidl") data size = 0 akonadi_pop3_resource_2(18205)/kio (KIOJob) KIO::TransferJob::slotData: mimeType() not emitted when sending first data!; job URL = KUrl("pop3://nassos%40kourentas.com@mail.kourentas.com:110/download/") data size = 0 It might seem weird, but the username of the email account is indeed: nassos@kourentas.com (and _not_ simply: nassos). Could this be the cause of the problem? But, then again, why is the above output generated _after_ the annoying weak certificate authenticity check dialogs? I would like to clarify the fact that the above issue is repeated each and every time that very pop3 account is checked for emails (that is every 1 minute as that's exactly the time interval I have configured in the corresponding pop3 account's settings, since I constantly receive input via that very channel...). Thus, it gets extremely irritating to be interrupted on a minutely basis from whatever else I might be doing :-( Should you have any further queries, please do not hesitate to contact me, I would once again like to thank you for your concern, Best wishes and a prosperous 2011, Nassos
Let's please not talk about the SSL certificate problem here, that is another bug (in kdelibs) and should get another bug report. Only talking about one issue per bug report makes things clearer. The output above is unfortunately only the warning output, not the debug output. This is either because your packages are built in release mode and not in debug mode, or because the POP3 debug output is not enabled in "kdebugdialog". > It might seem weird, but the username of the email account is indeed: > nassos@kourentas.com (and _not_ simply: nassos). Could this be the cause of > the problem? No, that is not the problem, my username is in the same form, and that works. > But, then again, why is the above output generated _after_ the annoying weak > certificate authenticity check dialogs? The certification check happens on the initial handshake, and the output above is from later stages. I indeed found a commit that was introduced in beta2 that is likely the cause for your authentication trouble. Basically the commit made the password dialog that was shown not work, the password entered there was never used. I'll commit a fix for that shortly. That should resolve this bug. For the certificate issue, please create a new bug report for the product kdelibs and tell me the bug number here, I'll poke the KSSL guy to have a look.
commit 820f3870fbba43358ae6a4f96c04b2153acc041d branch master Author: Thomas McGuire <mcguire@kde.org> Date: Fri Dec 24 23:37:52 2010 +0100 Make manual entry of password work again. This ceased to work after porting from KIO::Passworddialog to KPasswordDialog, since KIO::PasswordDialog stored the login and password into the variables passed by reference in the constructor, while KPasswordDialog doesn't do this. BUG: 260265 diff --git a/resources/pop3/pop3resource.cpp b/resources/pop3/pop3resource.cpp index 4398e1e..066c1db 100644 --- a/resources/pop3/pop3resource.cpp +++ b/resources/pop3/pop3resource.cpp @@ -192,14 +192,11 @@ void POP3Resource::walletOpenedForSaving( bool success ) void POP3Resource::showPasswordDialog( const QString &queryText ) { - QString login = Settings::self()->login(); - bool rememberPassword = Settings::self()->storePassword(); - // FIXME: give this a proper parent widget KPasswordDialog dlg( 0, KPasswordDialog::ShowUsernameLine | KPasswordDialog::ShowKeepPassword ); - dlg.setUsername( login ); + dlg.setUsername( Settings::self()->login() ); dlg.setPassword( mPassword ); - dlg.setKeepPassword( rememberPassword ); + dlg.setKeepPassword( Settings::self()->storePassword() ); dlg.setPrompt( queryText ); dlg.setCaption( name() ); dlg.addCommentLine( i18n( "Account:" ), name() ); @@ -208,7 +205,8 @@ void POP3Resource::showPasswordDialog( const QString &queryText ) cancelSync( i18n( "No username and password supplied." ) ); return; } else { - Settings::self()->setLogin( login ); + mPassword = dlg.password(); + Settings::self()->setLogin( dlg.username() ); Settings::self()->writeConfig(); Settings::self()->setStorePassword( false ); if ( dlg.keepPassword() ) {
(In reply to comment #4) > Let's please not talk about the SSL certificate problem here, that is another > bug (in kdelibs) and should get another bug report. Only talking about one > issue per bug report makes things clearer. > > The output above is unfortunately only the warning output, not the debug > output. This is either because your packages are built in release mode and not > in debug mode, or because the POP3 debug output is not enabled in > "kdebugdialog". > > > It might seem weird, but the username of the email account is indeed: > > nassos@kourentas.com (and _not_ simply: nassos). Could this be the cause of > > the problem? > > No, that is not the problem, my username is in the same form, and that works. > > > But, then again, why is the above output generated _after_ the annoying weak > > certificate authenticity check dialogs? > > The certification check happens on the initial handshake, and the output above > is from later stages. > > I indeed found a commit that was introduced in beta2 that is likely the cause > for your authentication trouble. Basically the commit made the password dialog > that was shown not work, the password entered there was never used. I'll commit > a fix for that shortly. That should resolve this bug. > > For the certificate issue, please create a new bug report for the product > kdelibs and tell me the bug number here, I'll poke the KSSL guy to have a look. I would once again like to thank you for your immediate concern! I already saw your next messasge (about the commit) which hopefully will resolve the issue. I'll also immediately proceed with creating a new bug report for kdelibs (and include the current bug as a reference). Thanks a lot, merry christmas and have a wonderful new 2011! Nassos
I assume you changed to status from FIXED to WAITINGFORINFO by accident? Changing back to FIXED now. Happy Christmas to you as well.
(In reply to comment #7) > I assume you changed to status from FIXED to WAITINGFORINFO by accident? > Changing back to FIXED now. > > Happy Christmas to you as well. Sorry if I did that, it was certainly by accident! nassos
> Sorry if I did that, it was certainly by accident! Weird, happened again.