On 5/19/24 2:29 PM, Chris M via tde-users wrote: If I remember correctly, on first launch of KMail, or perhaps on first password authentication, KMail prompts whether to use kwallet or store the password locally. I long have used the latter method. The password is hashed and stored in the user's kmailrc. For many people this is sufficient security. Within KMail->Settings->Accounts->Receiving-Modify is a check box option 'Store POP password'. I can't test at the moment, but I seem to recall this option configures KMail to store the password in the user's kmailrc file. Enabling this option creates a key 'store-passwd=true' in each kmailrc account configuration. The password itself is hashed in the 'pass=' key. Going back to the KDE 3 days, I suspect the underlying presumption within TDE is kwallet should be used to store credentials. This presumption seems to prevail with the modern KDE too. I can't vouch for kwallet but since the KDE 3 days I personally found kwallet a nuisance. I feel the same with KDE 5, which I use alongside TDE. A single encrypted password container is a useful idea, but I never grew warm and fuzzy about kwallet. The backend for TDE kwallet is built in tdelibs. The daemon can be seen in KControl->Service Manager->Load-on-Demand Services. There is a file /opt/trinity/share/services/kded/tdewalletd.desktop that contains the directive 'X-TDE-Kded-load-on-demand=true'. I have not experimented, but possibly this desktop file can be copied to $TDEHOME/share/services/kded/tdewalletd.desktop and the directive changed to false. If the file can't be copied, the primary file could be edited and tested.