Bug 2965 - Encrypted mails are stored unencrypted in 'Queue' while sending via IMAP
Summary: Encrypted mails are stored unencrypted in 'Queue' while sending via IMAP
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Plugins/Privacy/PGP (show other bugs)
Version: other
Hardware: PC Linux
: P3 normal
Assignee: users
: 2661 3336 (view as bug list)
Depends on:
Reported: 2013-07-12 18:31 UTC by CFP
Modified: 2015-07-04 12:00 UTC (History)
5 users (show)

See Also:

Claws Mail crypto handling (161.76 KB, image/png)
2014-09-06 16:32 UTC, innerand
no flags Details
Do not write unencrypted message to queue (9.03 KB, patch)
2015-06-18 09:28 UTC, Andrej Kacian
no flags Details | Diff

Description CFP 2013-07-12 18:31:04 UTC

I'm using Claws Mail for my accounts on GMX and web.de (IMAP).

The plugin(s) for Mail encryption (GnuPG) are installed and sending an encrypted email works. 

But there is a big problem (bug?!): Before sending the email, Claws Mail stores the mail automatically in the folder 'Queue' – unencrypted!
So after sending you find the mail encrypted in the 'sent' folder but before it is stored unencrypted in Queue (and transferred to the server). 

In fact this leads the encryption absurdity. 
Comment 1 Paul 2013-07-12 20:33:09 UTC
whilst this is being investigated, you can set your account's Queue (and Drafts?) folder to use a local MH mailbox's Queue (and Drafts) folder. (Use /File/Add mailbox/MH... if necessary)
Comment 2 CFP 2013-07-12 20:59:36 UTC
As you suggested, I created a MH mailbox and changed the Queue folder to "#mh/Mailbox/queue" and it seems to work. The unencrypted mail is no longer stored in the exteral folder. :)
Comment 3 innerand 2014-09-06 16:32:41 UTC
Created attachment 1428 [details]
Claws Mail crypto handling
Comment 4 innerand 2014-09-06 16:34:39 UTC
Is anybody still working on that? 

Claws Mail sends emails supposed to be encrypted in clear text to the internet. In my opinion this is a CRITICAL bug and it is open now for more than a year.
Comment 5 Brian Morrison 2014-09-07 19:18:28 UTC
Please see comment #1

This prevents any composed email prior to encryption or otherwise being stored on am IMAP server. It is completely effective.
Comment 6 innerand 2014-09-07 20:16:23 UTC
Well that might be an workaround but it doesn't fix the bug. Whereby it is also not good practice to write encrypted mails in clear text to disk. 

Is it that hard to encrypt mails before sending them to Queue?
Comment 7 Paul 2014-11-24 20:23:42 UTC
*** Bug 3336 has been marked as a duplicate of this bug. ***
Comment 8 sajolida 2015-04-27 15:47:01 UTC
The workaround proposed in comment #1 is also what we are about to recommend to our Tais users to do, see https://labs.riseup.net/code/issues/8999#note-14.

But I'm sad there is no real fix as people **will** fall in this trap unless they read our documentation because this problem is invisible (and people don't read doc until they actually face a problem, which is legitimate).

Do you think there could a way for us a Tails, to configure this workaround by default somehow in our template configuration file?
Comment 9 sajolida 2015-05-05 13:24:41 UTC
Here is the draft version of the security advisory that we are planning to release on Thursday, feel free to review it and comment:

Comment 10 Paul 2015-05-05 14:26:09 UTC
Although you may see it as pedantic, the use of language and correct terminology in advisories is important. First, there is no 'leak'. It is possible that Claws Mail stores plaintext copies of emails that are /due/ to be encrypted on the IMAP server, but the location of storage is, as you say, a choice made (or at least accepted) by the the user. It is not the case, strictly speaking, that "All users of Claws Mail using IMAP and its OpenPGP plug-in are affected." But only those who have made certain choices in their account configuration.

Anyway, this behaviour and how an unsuspecting user might be caught by it is known by the Claws Mail team, and finding an alternate method is on the TODO.
Comment 11 sajolida 2015-05-05 15:31:34 UTC
I'm a technical writer and I don't think that it's pedantic to take the time to find the correct words. I used the word "leak" because an information that the user is trying to hide from her email provider (using end-to-end encryption) is revealed against their will and without her noticing it. Which word would you propose instead?

The problem that we describe here happens with the default IMAP configuration in Claws Mails. The only configuration that prevents it from happening is the workaround that we are describing in [1] that uses folders from a local mailbox. 

I hope that you don't consider that an average user who wants to use OpenPGP and IMAP for end-to-end encryption should figure that out by herself and is otherwise not configuring Claws properly and not making the right choice. Claws Mail should have safe defaults when handling OpenPGP encrypted emails. We ourselves have been shipping Claws for years before realizing that this was happening.

[1]: https://tails.boum.org/blueprint/claws_mail_leaks_plaintext_to_imap/#index6h2

If you have a better fix to propose please share it with us. Until then we're glad to know that this is on your TODO list.
Comment 12 CFP 2015-05-05 15:57:18 UTC
I agree with sajolida.

The workaround is nice and it works without problems (claws-mail is great btw!).
But the problem is that nobody knows that he has to create a local MH, so innerand’s view that this is more a critical than normal "bug" is not that false at all.

In my opinion there must be a little warning when you install the PGP-Plugin that data could be leaked through the queue folder if you haven’t configured a local MH mailbox. 
A warning is necessary -- remaining silent about this bug is not that user-friendly…
Comment 13 geminiimatt 2015-05-10 17:19:45 UTC
I agree with CFP@public-files.de & sajolida. regardless of how this bug should be described. this should be fixed for the sake of user privacy / safety. 

Perhaps another solution is to automatically set a local queue folder for all users with imap on & encryption on. if one is not set then force the user to set one.
this could happen on compose of new message.

just looking at it quickly perhapsin compose.c at 6092 something like...

if (compose->privacy_system && compose->use_encryption) {
 queue = "#mh/Mailbox/queue"
 alertpanel_error(_("Using local queue '#mh/Mailbox/queue' for encrypted email:\n\n"), privacy_get_error());

Comment 14 Andrej Kacian 2015-06-18 09:28:39 UTC
Created attachment 1516 [details]
Do not write unencrypted message to queue

Attached patch should solve the underlying issue, by writing only encrypted message to queue. Please give it a try.

Note that it is still work in progress, some additional error checking needs to be done, but functionality is all there.
Comment 15 Andrej Kacian 2015-06-19 14:54:08 UTC
*** Bug 2661 has been marked as a duplicate of this bug. ***
Comment 16 users 2015-06-25 13:03:02 UTC
Changes related to this bug have been committed.
Please check latest Git and update the bug accordingly.
You can also get the patch from:

++ ChangeLog	2015-06-25 13:03:02.266979122 +0200
Merge: ea2993d 4e7e4f9
Author: Colin Leroy <colin@colino.net>
Date:   Thu Jun 25 13:03:01 2015 +0200

    Merge branch 'master' of file:///home/git/claws

Author: Andrej Kacian <ticho@claws-mail.org>
Date:   Sun Jun 21 22:22:12 2015 +0200

    Remove plaintext_file member of struct MsgInfo.
    It is no longer needed, as we no longer write unencrypted
    version of an encrypted message anywhere.

Author: Andrej Kacian <ticho@claws-mail.org>
Date:   Thu Jun 18 13:07:47 2015 +0200

    Encrypt message just before writing it to queue dir.
    This fixes bug #2965.
    As a side effect, if "Save sent encrypted messages as clear text" is
    enabled, a copy will be saved to outbox when queuing, not when sending.

Note You need to log in before you can comment on or make changes to this bug.