Version: unspecified (using KDE 4.5.90) OS: Linux KMail gives the following error message if I try to enter a password for an SMTP server: KWallet is not available. It is strongly recommended to use KWallet for managing your passwords. However, the password can be stored in the configuration file instead. The password is stored in an obfuscated format, but should not be considered secure from decryption efforts if access to the configuration file is obtained. Do you want to store the password for server 'smtp.gmail.com' in the configuration file? It then offers the options 'Store Password' and 'Do Not Store Password'. However, KWallet seems to be fine so the error message is unjustified. I apparently worked around the problem by simply sending an e-mail through the specific SMTP server. Then KMail asks for the password on it's own initiative, and then the password also appears in the settings. Without any further complaints that KWallet is unavailable. This also means that I can no longer reproduce the bug. This is on KDE SC 4.6 RC1 with KDE PIM 4.6 beta 3. Reproducible: Didn't try Steps to Reproduce: Not sure how it started to happen. For the first e-mail account I added KWallet stored the passwords fine, now that I have added a second one it starts complaining when I need it to remember the passwords for the SMTP server. The password for the IMAP server is remembered correctly.
I have similar issues in KDE 4.6 RC1 with PIM beta3 under Kubuntu 10.10. From time to time Kmail cannot recall a password for POP/SMTP servers from Kwallet. When I do not enter the password into the dialogue, but click on abort and try to check for new mails again it works. I am not sure how to reliably reproduce this behaviour, it appears only sometimes, especially when I recently startet Kontact. Is Kontact running for some hours I did not see this bug.
My experience: If you set up an smtp account and tick to store the password, you get the error saying: "KWallet is not available. It is strongly recommended to use KWallet for managing your passwords. However, the password can be stored in the configuration file instead. The password is stored in an obfuscated format, but should not be considered secure from decryption efforts if access to the configuration file is obtained. Do you want to store the password for server 'smtp.gmail.com' in the configuration file?" If you choose to save to configuration file then Kmail doesn't seem to be able to use that either, and emails are stuck in outbox. My workaround is not to store the smtp password at all, but rather enter it every time I send an email. I don't know about POP accounts since I'm using IMAP, and Kmail seems to be able to access the account's password. This is with final KDE 4.6 release, and Kmail 1.13.5.
I can confirm this for my IMAP accounts. Since 4.6 the passwords aren’t stored anymore.
Another confirmation, I have several email accounts and this has been driving me nuts.
Same problem on Kubuntu Natty with KDE 4.6.1 and KMail 4.4.10
I suppose this is not a problem in KMail itself, but more in kdepimlibs
*** This bug has been confirmed by popular vote. ***
Same in KMail 1.13.7 using KDE Platform 4.6.2. Arch Linux packages, home directory on NFS, Kopete is working fine with KWallet.
When I created a new account this problem turned up again, but with a twist. When I entered the password for the SMTP server of the new account KMail complained that it could not use KWallet for the password, and offered that it would store the password itself. Then, when I opened Kontact again the next day or so, KWallet somehow was available to KMail again and it offered to migrate the stored password to KWallet. I did so and then everything was fine. Unfortunately I can't give screenshots or exact messages describing what happened, it happened a few days ago and I didn't document what happened exactly. This happened with KMail 4.6 beta 5 on KDE 4.6.2.
Any progress on this, it makes sending email in KMail a serious nuisance.
Holy cow, this is still broken in 4.7.0!
Still broken in KDE 4.7.0 (Kontact Version 4.7.0) It started in 4.6 after migration. Still was there after removing everything in akonady resources management and re-configuring all accounts from scratch.
Still broken in KDE 4.7.0 running on Arch Linux, same symptoms as everyone above.
I am hit by this bug anytime I am changing preferences of the sending account. Specifically, in some networks I need to change the transport protocol from SSL to TSL. Anytime I do that I get the "Kwallet integration issue". Maybe the kwallet sees conflict in properties of the account?
I have noticed that if I manually delete the entry in KWalletManager and then send an email, telling KMail to save the password, the KWallet entry reappears! Thus, it appears that KMail stores the password just fine, but doesn't retrieve it. I am using KMail 4.7.3 on Kubuntu 11.10.
I can confirm this bug for KMail 4.8.0 running in Gentoo Linux. Each time after reboot I have to stop and restart KMail. After the second start it gets the passwords fine. This bug is annoying lots of people for a long time now. Will there be a solution?
I do not know if it is related, but I have similar problems with the network manager plasmoid. I suspect the bug (if it is the same one!) is in kwallet rather than kmail2 or akonadi.
Happening for me with KMail2 v4.8 too. If it's a bug with kwallet, maybe the reason nobody's looking at it is: http://techbase.kde.org/Projects/Utils/kwallet ==> "NOTE: kwallet will be replaced by Projects/Utils/ksecretsservice" Do we know that there ARE any devs looking at what the users have reported here?
are these the same issue? https://bugs.kde.org/show_bug.cgi?id=293271 https://bugs.kde.org/show_bug.cgi?id=295010
Fixed in 4.10
Not fixed kmail-4.10.5-1.100.2.x86_64 openSUSE 12.3 kmail uses passwords from kwallet for IMAP retrieval, and by the looks of it for other SMTP servers, but there's always one for which it doesn't. It's been driving me nuts...
4.10.5 is very old. But could you explain me how to reproduce it. Which is the exact message error?
Reboot. Click send. Popup message is: "You need to supply a username and password for this SMTP server". It offers to save it, I say yes, it gets stored in ~/.kde4/share/config/mailtransports Log out, make sure all user processes exit (console shell to check). Log in, start kmail, it asks "password stored insecurely, migrate to wallet" (or to that effect). Click yes. Compose email, click send. Popup "you need to supply a username...". I got the impression that kmail does not read the password from mailtransports either - but to be confirmed. I have 10 SMTP accounts and about 12 IMAP accounts configured. The problem has become seriously annoying more recently, about when I replaced mobo and CPU with faster ones. Hmm, at least 2 SMTP servers are affected. If it was only a config problem that'd be cool, but I can't think of one. I do frequently run kmail over ssh on the LAN, but that has always worked earlier. I take care of stopping akonadi appropriately (akonadictl stop) and running a dbus daemon per display. On startup kmail causes a popup asking for the wallet password; it still does, but it is no longer sufficient. kdeinit4: kwalletd is running, kwalletmanager is started by kmail when asking for a pasword. Every linux distro and KDE version is very old all the time :-) The problem is that you don't have the resources to deal with more than leading edge, and I don't have the resources to keep up and deal with the problems after each upgrade/reinstallation of $DISTRO. Thanks for looking over it thoguh.
"Log in, start kmail, it asks "password stored insecurely, migrate to wallet" (or to that effect). Click yes. Compose email, click send. Popup "you need to supply a username..."." it's the exact string ? I can't find it. It's kmail which told it or kwallet etc ?
Created attachment 89408 [details] Kmail pop-up migrating passwords. I have two SMTP servers now whos pw kmail won't read from the wallet. I think it still reads some from the wallet though. It's affecting GMX and Posteo - both might have turned off sslv3 recently and I think I edited the transport settings accordingly.
Thanks for infos. I found code. I will able to investigate it.
I investigated this morning, fixed another bug (save password at the first time in mailtransportrc) but I can't reproduce migrate bug. It migrated correctly here. I don't see in source code a bug about it.
We use it to store password in wallet: void Transport::usrWriteConfig() { if ( requiresAuthentication() && storePassword() && d->passwordDirty ) { const QString storePassword = d->password; Wallet *wallet = TransportManager::self()->wallet(); if ( !wallet || wallet->writePassword( QString::number( id() ), d->password ) != 0 ) { => the problem can be that we can't write in kwallet or kwallet is never open by mailtransport. To know if password is stored in kwallet open: ~/.kde/share/config/mailtransports => search group where there is your password go to kwalletmanager search: (in mailtransport file we have config group as "[Transport 1816781056]") => search "1816781056" (your real number not mine :) ) and you will show if it's stored in kwallet.
Thanks Laurent! I can confirm that kmail reads some passwords from kwallet for sending, but not others. This one is NOT read from kwallet, although it is stored in the wallet (searching for the transport number): [Transport 113691....] auth=true authtype=1 encryption=TLS host=mail.gmx.net id=113691.... name=GMX ... password=... (!!) storepass=true user=.... Migrating it will cause kmail to start prompting for a missing password. (Does the migration fail if a password is already stored, same password or not same?) The password for this one is loaded correctly from kwallet: [Transport 12163....] auth=true authtype=1 encryption=TLS host=....net.nz id=12163.... name=... port=587 storepass=true user=... Other than the port number I don't see a difference for the two entries.
"Migrating it will cause kmail to start prompting for a missing password. (Does the migration fail if a password is already stored, same password or not same?)" interesting question :) I will investigate in this direction. Thanks for giving me an new way to investigate. But why you still have same identifier + password in kwallet ?
> But why you still have same identifier + password in kwallet ? One of two reasons: * It's still in there from before, when kmail was reading the password from kwallet correctly. * kmail migrated it into kwallet, but on next complete restart complained about a missing password, asks for it, stores it into mailtransports, then asks whether to migrate it, and round we go.
I looked at in code and it can replace existing password. Perhaps you can try to remove in kwallet this entry, try migration and look at if you have still bug or not. For the moment I don't see the problem.
I had two SMTP servers with passwords in the mailtransports file. I deleted both from kwallet, quit kmail, and stopped KDE PIM akonadictl stop qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit mysqladmin --socket=$USER/.local/share/akonadi/socket-$HOST/mysql.socket shutdown Starting kmail and composing an email with a sender ID belonging to one of the SMTP servers under test causes kmail to prompt for the password. Good. However, when attempting to store it kmail says "KWallet is not available". kwalletd is running afterwrads with no other app started that could have caused kwallet to be started.
Created attachment 89467 [details] kmail notification that kwallet is not available.
kwallet is not available ? but your password from imap/pop3 is stored in kwallet. Very wierd. Perhaps a bug in your old kwallet.
> kwallet is not available ? but your password from imap/pop3 is stored in > kwallet. Yes. Crazy. Receiving mail always works as expected. And I'm sure it used to work for sending too, the only changes I can remember making is verifying the encryption settings and adding the odd mailbox and (less often) SMTP server.
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.