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
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?
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.
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.
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?
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?
The Network log looks like this when it happens: http://pastebin.com/KPfWJfrn
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.
If you uncheck "Save sent messages to Sent folder" under Configuration >> Preferences... >> Mail Handling >>> Sending, the problem goes away.
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"
Look under the tab privacy
No, I encrypt to myself; that greys out the box that saves as cleartext.
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...'
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.
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
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.
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.
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.
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.
Hi, 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!): https://labs.riseup.net/code/issues/8999 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?
(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.
Ok indeed, I'll move there.
*** This bug has been marked as a duplicate of bug 2965 ***