Bug 2661 - Unencrypted e-mail gets saved on IMAP server
Summary: Unencrypted e-mail gets saved on IMAP server
Status: RESOLVED DUPLICATE of bug 2965
Alias: None
Product: Claws Mail (Windows)
Classification: Unclassified
Component: default (show other bugs)
Version: 3.8.0
Hardware: PC Windows NT
: P3 normal
Assignee: users
Depends on:
Reported: 2012-05-16 00:13 UTC by Abdull
Modified: 2015-06-19 14:54 UTC (History)
3 users (show)

See Also:


Description Abdull 2012-05-16 00:13:25 UTC
I'm using Claws Mail (via gpg4win-light-2.1.1-svn1694-colin.exe) for my Google Mail account to send encrypted e-mails.

In my Claws Mail Google Mail account preferences:
*e-mails get encrypted and signed.
*I'm using PGP MIME.
*I deactivated the option "Save encrypted e-mails as plaintext" (original German: "Verschl
Comment 1 Paul 2012-05-16 06:57:54 UTC
You already have this encrypted with your own key: you said you chose the option "Encrypt e-mail with other key AND own key". I don't use windows so cannot check, but are you sure that what you are seeing is not just the _automatically decrypted_ copy of your saved version?
Comment 2 Abdull 2012-05-16 11:37:00 UTC
I'm sure I'm seeing the original message, not an automatically decrypted message: When I log in via Google Mail's web interface ( https://mail.google.com ), I can see my unencrypted e-mail. The Google Mail webmail client doesn't support anything PGP- or cryptography-related, therefore my mails cannot be automatically decrypted via the Google Mail web interface.
Comment 3 K. C. Juntunen 2012-07-05 06:07:36 UTC
I can confirm this problem in Linux as well. I'm using version 3.8.0 in Fedora 17. I first noticed in a Windows client. The longer the email, the more copies end up unencrypted on Gmail. I wonder if the Importance shouldn't be upgraded since it defeats the purpose of encryption.
Comment 4 Paul 2012-07-05 08:29:32 UTC
I cannot reproduce this problem. Encrypted messages I send with my gmail account remain encrypted in the gmail Sent folder.

In which gmail folder do you see these unencrypted mails?
Comment 5 K. C. Juntunen 2012-07-05 13:32:26 UTC
I find it in [IMAP]/Sent on the Gmail web interface.

After some more testing, I see it happens with either Inline, or MIME PGP modes. "Automatically save to Drafts folder" can be off or on. I've had as many as two dozen cleartext copies of an encrypted email sent to Gmail in the [IMAP]/Sent folder. Only the encrypted copy makes it finally to its destination (apparently), but the plaintext is still hitting the Internet.

Is it a problem with the PGP Core plugin perhaps?
Comment 6 K. C. Juntunen 2012-07-05 13:39:28 UTC
The Network log looks like this when it happens: http://pastebin.com/KPfWJfrn
Comment 7 K. C. Juntunen 2012-07-05 13:44:30 UTC
Another detail: When taking the time to type a message, I get many partial-to-complete cleartext copies in [IMAP]/Sent. If I just paste in a big chunk of text for testing, I get one full cleartext copy in [IMAP]/Sent.
Comment 8 K. C. Juntunen 2012-07-06 00:50:56 UTC
If you uncheck "Save sent messages to Sent folder" under Configuration >> Preferences... >> Mail Handling >>> Sending, the problem goes away.
Comment 9 Michael Rasmussen 2012-07-06 01:28:33 UTC
If you open the account in questions settings do you then have a check mark where it says: "Save encrypted send messages in clear text"
Comment 10 Michael Rasmussen 2012-07-06 01:29:08 UTC
Look under the tab privacy
Comment 11 K. C. Juntunen 2012-07-06 04:01:51 UTC
No, I encrypt to myself; that greys out the box that saves as cleartext.
Comment 12 Paul 2012-07-06 08:22:41 UTC
comment #7 suggests that you're using your Sent folder as a Drafts folder.
In the standard preferences, on the Compose/Writing page, turn off 'Automatically save messages to Drafts folder...'
Comment 13 K. C. Juntunen 2012-07-06 22:53:22 UTC
I turned off 'Automatically save messages to Drafts folder...' earlier; after that it seemed to only save a single cleartext copy (it never saved anything in the '[IMAP]/Drafts' folder anyhow). 

The problem only went away when I turned off 'Save sent messages to Sent folder...'under 'Configuration' >> 'Preferences...' >> 'Mail Handling' >>> 'Sending'

If that's not a bug, I'd think there should be a warning about it in the documentation.
Comment 14 Tommi 2013-03-31 01:16:44 UTC
I also encountered this problem.
This is a severe security issue and I wonder why this only has "P3 normal" as importance!

Using: Debian Wheezy + claws-mail 3.8.1-2 using pgp-core, pgp-inline and pgp-mime plugins against gmail through IMAP.
Config: Configuration -> Preferences for current accounts -> Account -> Advanced -> Put sent messages in gmail "Sent Mail" directory through IMAP.
Action: Send an encrypted mail
Effect: Every sent mail will appear as two in http://mail.google.com "Sent Mail" directory, one of them containing the expected encrypted text unencrypted in human readable form
Comment 15 Intactivist 2013-08-12 07:13:33 UTC
I followed the guide to setting up Gmail in Claws Mail and also encountered this problem. This is not a bug. There should be a warning on these guides, however.
Comment 16 sercher 2014-07-15 16:52:08 UTC
In fact, plaintext emails are being _temporarily_ saved (to the 'Queue' folder) even if you uncheck the 'Leave a copy in the Sent folder' checkbox. Please see the network log below.

[18:06:18] IMAP4> 56 APPEND Queue (\Seen) {1981} 
[18:06:18] IMAP4< + go ahead 
[18:06:18] IMAP4> [data - 1983 bytes]
[18:06:19] IMAP4< * 2 EXISTS 
[18:06:19] IMAP4< 56 OK [APPENDUID 48 37] (Success) 
[18:06:19] IMAP4> 57 NOOP 
[18:06:19] IMAP4< 57 OK Success 
[18:06:19] IMAP4> 58 UID FETCH 37 BODY.PEEK[] 
[18:06:20] IMAP4< * 2 FETCH (UID 37 BODY[] {1981} 
[18:06:20] IMAP4< AF: 
[18:06:20] IMAP4< NF:0 
[18:06:20] IMAP4< PS:10 
[18:06:20] IMAP4< SRH:1 
[18:06:20] IMAP4< SFN: 
[18:06:20] IMAP4< DSR: 
[18:06:20] IMAP4< MID: 
[18:06:20] IMAP4< CFG: 
[18:06:20] IMAP4< PT:0 
[18:06:20] IMAP4< S:my_user_id
[18:06:20] IMAP4< [FETCH data - 388 bytes]
[18:06:20] IMAP4< [FETCH data - 514 bytes]
[18:06:20] IMAP4< [FETCH data - 1015 bytes]
[18:06:20] IMAP4< 58 OK Success 
[18:06:20] IMAP4> 59 UID STORE 37 +FLAGS.SILENT (\Seen) 
[18:06:20] IMAP4< 59 OK Success 
* Account 'my_user_id@gmail.com': Connecting to SMTP server: smtp.gmail.com:465...
[18:06:20] SMTP< 220 mx.google.com ESMTP wm3sm6953181lac.43 - gsmtp
[18:06:21] SMTP> RCPT TO:<recepient_email@yahoo.com>
[18:06:21] SMTP< 250 2.1.5 OK wm3sm6953181lac.43 - gsmtp
[18:06:21] SMTP> DATA
[18:06:21] SMTP< 354  Go ahead wm3sm6953181lac.43 - gsmtp
[18:06:21] SMTP> . (EOM)
[18:06:22] SMTP< 250 2.0.0 OK 1405433179 wm3sm6953181lac.43 - gsmtp
* Mail sent successfully.
[18:06:22] SMTP> QUIT
[18:06:22] SMTP< 221 2.0.0 closing connection wm3sm6953181lac.43 - gsmtp
[18:06:22] IMAP4> 60 UID STORE 37 +FLAGS.SILENT (\Deleted) 
[18:06:22] IMAP4< * 2 EXPUNGE 
[18:06:22] IMAP4< * 1 EXISTS 
[18:06:22] IMAP4< 60 OK Success 
[18:06:22] IMAP4> 61 EXPUNGE 
[18:06:22] IMAP4< 61 OK Success 
[18:06:22] IMAP4- [fetching UIDs...]
[18:06:22] IMAP4> 62 UID FETCH 1:* (UID) 
[18:06:22] IMAP4< * 1 FETCH (UID 36) 
[18:06:22] IMAP4< 62 OK Success 
[18:06:22] IMAP4- [fetching flags...]
[18:06:22] IMAP4> 63 UID FETCH 1:* (FLAGS UID) 
[18:06:23] IMAP4< * 1 FETCH (UID 36 FLAGS (\Seen)) 
[18:06:23] IMAP4< 63 OK Success 

This is certainly a bug, that defeats the purpose of email encryption.
Comment 17 Brian Morrison 2014-07-15 17:14:27 UTC
The way to fix this is to create a local MH mailbox on your machine and point the sent and queue (and any others you want) to that local mailbox. Then your encrypted mail will not be stored on the IMAP server.
Comment 18 sercher 2014-07-16 10:46:30 UTC
Thanks Brian,

> The way to fix this is to create a local MH mailbox on your machine and
> point the sent and queue (and any others you want) to that local mailbox.

Could there be any workaround on how to "point the sent and queue" under Windows?

> Then your encrypted mail will not be stored on the IMAP server.

That would be just great. However this is not much of an issue, that the encrypted emails are stored. What I'm saying is that Claws shouldn't be uploading the plain texts. Well, there's no benefit in storing the encrypted emails anyway, because only the recipient can decrypt it, so it should be disabled by default.
Comment 19 sajolida 2015-04-26 22:15:05 UTC

I'm part of the people developing Tails (https://tails.boum.org/). I've look for a development mailing on your website but couldn't find any, so I'm writing here.

We discovered this bug in Claws Mail only recently and we are very concerned about it.

Our users use Tails and Claws to work on very sensitive stuff and having drafts and queued emails sent in plaintext to the remote server is a critical security issue.

We're tracking this bug on our own bug tracker (duplication, yeah!):


We tried to work around it to fix the issue in Tails but couldn't a way of doing it. See https://labs.riseup.net/code/issues/8999#note-10.

So we are considering issusing a security advisory to all our users and document a manual workaround. See https://labs.riseup.net/code/issues/8999#note-14.

We were wondering how we should interact with you regarding this (and if this is of interest to you of course):

Would you be interested in been given some time to patch the issue for good? We think Claws should propose to store drafts and queued emails encrypted to the user's public key when saving them on remote server, either by asking on first time (better) or by having a configuration for that that we set by default in Tails.

Otherwise, would you like to help us find a better work around Would you like to see the draft of our security advisory?
Comment 20 Paul 2015-04-26 22:23:25 UTC
(In reply to comment #19)

This is discussed on bug #2965 and that is probably a better place for you, rather than this "Claws Mail (Windows)" entry. Please read the comments on that entry where a suggested workaround is mentioned.
Comment 21 sajolida 2015-04-27 15:43:52 UTC
Ok indeed, I'll move there.
Comment 22 Andrej Kacian 2015-06-19 14:54:08 UTC

*** This bug has been marked as a duplicate of bug 2965 ***

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