[kdepim-users] smtp password blues: "kwallet is not available"

[René J.V. Bertin]

Hi,

This is the 2nd time I've had to jump through too many hoops to get akonadi's sendmail source to talk to kwallet again.

Background: I have my passwords stored in a kwallet, including the ones for my various smtp servers. To make this a bit less insecure, wallets close after a timeout (and/or when the last client disconnects).

There are times I do not immediately catch a wallet unlock request when sending email, and instead of waiting patiently until I do and unlock the wallet, the mail dispatcher apparently considers that the wallet is not available. Without as much as cancelling the kwallet request (the dialog stays up), the dispatcher posts its own dialog to enter the smtp credentials, with the option of storing them.

Here, storing means in the "mailtransports" settings file, with just some kind of binary encoding.

The dispatcher agent could of course attempt to store the creds in the kwallet, or it could allow you to cancel its dialog and attempt to obtain the creds from the kwallet when you try to flush the outbox and/or send another email.

None of all that: "kwallet not available" is apparently considered a definitive state from which recovery is not possible or in any case not foreseen. You have to restart the dispatcher agent to make it forget the transient communication glitch with kwalletd.

Am I the only one banging my head against this kind of issue?

- wallet requests shouldn't time out. And they don't with other applications, as far as my experience goes.
- if they do, that's not a reason to consider that the kwallet system isn't available. There are other ways to determine whether that's the case, but as long as you can obtain valid information about the wallet(s) configure (name[s], number) it is safe to assume that the system is available. Most of these calls don't require unlocking the wallet.
- so if a password request through kwallet fails, the code should just try again. And again. Until the user takes action to address any non-transient errors there might be.
- AFAIC it's fine to post a dedicated login dialog when a kwallet call fails, but it should not become the only way of authenticating to the server for the reset of the dispatcher's lifetime. It seems that the code is conceived to try twice to get the creds before giving up; that 2nd time simply ought to try the kwallet again. Chances are the user already unlocked it because the dialog was up anyway, and that the call goes through immediately.

R.
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users