Bug 314080 - Encryption preferences bring up encryption dialogue even when no encryption selected, mail sent plain
Summary: Encryption preferences bring up encryption dialogue even when no encryption s...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kontact
Classification: Applications
Component: mail (show other bugs)
Version: 4.10 pre
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-29 15:02 UTC by Georg Greve
Modified: 2017-01-07 22:18 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Georg Greve 2013-01-29 15:02:35 UTC
When one of the recipients has "Encrypt Whenever Encryption is Possible" set in their preferences, trying to send a mail always brings up the encryption dialogues for key selection. 

This is as it should be. 

But when no encryption has been selected in the editor, the encryption dialogue is still brought up, and when selecting the final "Encrypt" the mail is then sent plain.

That is not as it should be.

Encryption does however work as expected when encryption has been turned on for this message.

Reproducible: Always

Steps to Reproduce:
1. Set encryption preferences for recipient to always encrypt
2. Compose mail to recipient, do NOT turn on encryption in editor
3. Send message, click through all the encryption dialogues
4. Watch mail go out unencrypted
Actual Results:  
Mail is sent plain to "always encrypt" recipients when no encryption is selected in editor.

Expected Results:  
Mail should be sent encrypted to "always encrypt" recipients also when no encryption is selected in editor.
Comment 1 Dennis Schridde 2014-08-03 21:32:30 UTC
I confirm this, or something very similar.

1) I write an email for a contact that has no addressbook entry, yet, and press the "encrypt" button in the mail editor. Upon sending the mail, I am being asked which keys to use and I select "Encrypt whenever encryption is possible" from the drop down menu, which defaults to "<none>".

2) Right afterwards I compose a second email for the same contact and press the encrypt button as before. Upon sending the mail I am being asked which keys to use. "Encrypt whenever encryption is possible" is still chosen, but the "encrypt" button was not selected automatically.

3) I compose another email to said contact and do not press the encrypt button, which is not automatically selected – the email goes out unencrypted.

4) A few reboots later, after adjusting the "encrypt whenever encryption is possible" setting again, I compose another email for the same contact, press encrypt and send the email. I am being asked for the keys and "<none>" is now selected again – the "encrypt whenever encryption is possible" choice has been forgotten.

5) I create a addressbook entry for the contact, start composing an email for him by clicking his email address in the To: field of another email, and "encrypt" is not automatically selected. Pressing "Send" sends an unencrypted email.

Expected behaviour:
1) Selecting "encrypt whenever encryption is possible" should be saved permanently.
2) Akonadi should somehow ask to store the contact permanently, if trying to save encryption settings for a contact that is not permanently saved in any resource.
3) Selecting "encrypt whenever encrpytion is possible" should enable encryption automatically when having the contact in the To: field of any newly composed email.
Comment 2 Dennis Schridde 2014-08-03 21:33:44 UTC
This is using Kubuntu 14.04.1 with KDE 4.13.2.
Comment 3 Denis Kurz 2016-09-24 19:31:49 UTC
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 kontact (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 4 Denis Kurz 2017-01-07 22:18:58 UTC
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.