Version: (using KDE KDE 3.3.1) Installed from: SuSE RPMs It would be nice to have an option "encrypt message" on RECEIVED mails. With this option it would be possible to store received mails in the local (or imap) folders encrypted even the sender didn't encrypt them. So messages can be secured from being read by unwanted eyes. I know it's possible to use encrypted file systems or save messages as text and encrypt them. But kmail/kontact offers a more than very good application to manage mails (and more).
Even though I'm not one of the developers, in my opinion this would be a bad idea. With this logic _every_ program should have to include its own encryption backend because the data it handles is possibly sensitive. General encryption of files should be handled as such: encrypted files or filesystems. For Linux there are quite comfortable solutions: * a dm-crypt encrypted filesystem can be automatically mounted at login by pam_mount. * encfs (based on fuse) encrypts on a file by file basis, i.e. without the need for a partition or image file.
Maybe "encryption" is the false approach for my idea. When using Outlook you can protect the "mail store" against unauthorized access with a password. AFAIK it's named "compressable encryption" and "optimized encryption" (have only the german version, so i don't know the exact label). So it is not possible zu access someones mail store. This is independent of using IMAP or POP3. As kmail stores the downloaded mails as flat files on disk, the is no protection above the files access modes (user,group). As on many systems the "mask" is set to minimum "group readable" there's no security. Using encrypted file systems is good on single user machines. But - we use LTSP (www.ltsp.org) for near 100 Users on a single server. There still is the posibility to encrypt a single mail (file) with gnupg using konqueror. But which file is the correct mail, what does kmail with an encryted mail file? So i thought about a context menu option like "encrypt mail by gpg" within kmail.
*** Bug 127830 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Even though I'm not one of the developers, in my opinion this would be a bad > idea. With this logic _every_ program should have to include its own encryption > backend because the data it handles is possibly sensitive. That's a strange argument as far as IMAP storage is concerned. Please mind that more and more people switch from POP3 to IMAP. There is no other option for protecting data on IMAP. It would be neither a program-specific backend (because you can use GPG for any kind of data) nor be new as kmail already has the capability to decrypt and encrypt emails. The only change would be to encrypt a received mail instead of a sent one. > General encryption of files should be handled as such: encrypted files or > filesystems. Correct but irrelevant as this is not an option for those who use an IMAP service provider (does not make sense to propose everyone might set up his own IMAP server just in order to get around this simple and elegant solution by forcing volume encryption to become an option).
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding.
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.
(In reply to comment #6) > Instead of creating a new feature request, please confirm here if the > wishlist is still valid for kmail2. Still valid. And I would like to extend this feature wish by something that is technically very close: Keys get revoked. And of course, you never know when. The moment a key is revoked all its signatures become worthless – unless you can prove (or be sure if it's for yourself only) that the signature was made (long enough) before the revocation. The protection if IMAP accounts is many orders of magnitude weaker than that of crypto. Thus it would be nice if KMail was able of signing incoming emails. Technically it is AFAIK not possible to sign an already signed email without breaking the message format but instead an additional IMAP mailbox could be created where no email format messages are stored but simply the detached signatures of the normal emails. Those signature files could be named by the message IDs or by the hash values of the emails (or just of the signed part). The last step to happiness would be to prepare for further handling of these signatures by the option to deliver them locally to some program / script (which may request a crypto timestamp from a third party in order to be able to really prove that the signature is valid in case it gets revoked later).