Open Bug 280588 Opened 20 years ago Updated 2 years ago

Encrypted email messages should be stored decrypted in the local folders

Categories

(MailNews Core :: Security: OpenPGP, enhancement)

Product:
MailNews Core
Component:
Security: OpenPGP
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: wtc, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [datalossy]) 

If a user saves an encrypted email message in a
local folder, the email message should be stored
in the clear (decrypted), with any signatures
intact.

Email encryption should only be used for email
transport, not for storage.  If the locally stored
messages need to be encrypted, they should be
encrypted using a different method.  (Perhaps
local mail folder encryption should be a related
enhancement request.)

This will reduce the need to keep many old private
keys around to decrypt old encrypted email messages.
This would also solve the issue of searching the body of encrypted mails, which is not possible as of now. See https://bugzilla.mozilla.org/show_bug.cgi?id=188988
and
https://bugzilla.mozilla.org/show_bug.cgi?id=260665
Nelson, thoughts on this? Are we going to get an equal number of complaints if we stop encrypting the local store?
In my opinion, S/MIME and PGP are mechanisms to encrypt the email transmission over the public Internet, and not to encrypt the local user's mailbox. There are other ways to do that (put your Maildir in a cryptoloop, secure your system). 

An email archive that cannot be searched is useless to me. If I lose one of my old private keys, the corresponding archived messages are lost forever.

BTW mutt has a feature to search encrypted messages and another feature to save a decrypted copy to the mail folder.
I think the answer is 'yes'.

This bug really should be 'figure out how to manage encrypted messages better'.

The problem isn't necessarily that the email is stored in the local folder encrypted, the problem is under certain conditions the user may loose access to old email if he looses his private key. Changing the subject to the real problem, however, will get it closed with the statement "of course, that is the way it is supposed to work".

This bug is really a place holder for figuring out when and how we deal with encrypted email. For some use, encrypted email is encrypted for transport reasons (that is they are sent through untrusted channels). Once that email arrives there is no further reason for maintaining encryption. In this case we should decrypt the message immediately.

Some usage cases are such that the message itself must be protected, in perpetuity, no matter how much it's is 'copied'.

We need to work out each scenario and determine the correct semantic without resorting to a ton of user options. The proposal is a pretty good first cut compromise for an IMAP based email system.


Oh, so the proposal is that if an encrypted imap message is copied to a local folder, it should be decrypted. I see...and that should be an OK default. Seems reasonable. 
I think it would be fine to give the user the *option* of storing messages in
decrypted form, but I certainly would not take away the capability of 
working as it does now, preserving the original message intact in the folder.

Since we have no encryption/password protection for our local mail folders,
I very much want encrypted mails to remain encrypted in my folders at all 
times.  

Question about the original proposal.  If the objective is to improve searchability of messages, then in addition to decryption, should we also 
decode base64 and quoted printable, and store the results?
There is no doubt that encrypted messages in an IMAP folder should stay encrypted as they are.

Securing data in the local mail folders is neither PGP's or S/MIME's task, nor is it Thunderbird's task. It can simply be done by setting the right file permissions, choosing a good login password and all other means we do to keep others from accessing our data. The paranoid of us can still use an encrypted file system, or put their mail folders on a USB stick.

Having the option to decrypt messages when saving them to a local folder would provide searchability without further implementation. Searching in encrypted messages could be a problem: on every first search the user will have to enter the passphrases for all the keys he/she uses (e.g. one key per email address) and all encrypted messages need to be decrypted and searched in the background in a secure manner. This may be slow and annoying.
Christoph,

The user will only need to enter one password for each token that stores keys. If the user stored all his private keys in the NSS database (internal softoken), then he will only need to enter a single password at the time the search function finds the first encrypted e-mail. Under most circumstances, the program stays logged in to the token, so it is only a one-time password prompt.

If the user has multiple private keys that aren't all stored in the same token, and not all the tokens can be connected to the machine at the same time (eg. the user has 10 USB keys with one key each, but only 2 USB ports - or 2 smartcards but only one smartcard reader), then the search function wouldn't work, unless it asked the user to plug in the token that may contain the missing key for each message. This would be much more annoying than just a password prompt, and I don't think anybody would want that behavior ;)
QA Contact: general
Assignee: mscott → nobody
One possible user-interface: If a user right-clicks on the mail message, one of the options would be to "Create decrypted copy". If this option is chosen a decrypted copy is stored in the same folder as the encrypted folder. 

It would be important to ensure that the new mail message have a clear indication that it is a copy of an encrypted e-mail message and perhaps when it was created (e.g., "This decrypted copy of an encrypted email message was made on MM/DD/YYYY"). Otherwise, the user might come back to the message at a later date and, forgetting that he had created a decrypted version, think that the original message was sent in the clear and start to panic.
This topic or issue has come to a dead end - 

It appears that there are only two options - 

1. leave as is - messages remain encrypted
2. provide means to save messages in a decrypted form

So obviously, allowing the user interface that provides for the option to choose option 2 is all that is needed.

There are probably many reasons for and against, but allowing the user an option appear to be the way forward.  Anyone disagree?

So how do we energize this to move in that direction?

We chose to use Thunderbird over Outlook, but not having this option to save messages in an unencrypted state is a very big issue that may force us to abandon Thunderbird and migrate to Outlook instead.

There are work arounds to circumvent this, but it really taints Thunderbird as being "kludgy" when we know that it is far from that :-)

Let's get energized and FIX this!

Please let me know if there is anything that we can do to assist.

Thanks!
I would support such an option. Not sure if there are takers to work on this bug however. Copying David Bienvenu since he might do some related stuff.
I would really like to see an option to be able to save encrypted emails in an unencrypted format.  I believe Eudora had this feature.  Unfortunately, I am not a programmer, but if there is any way I can help let me know.
3.5 years after writing comment 6, I will add this perspective in reply to 
comment 10:
> This topic or issue has come to a dead end - 

All significant development on the S/MIME signed and/or encrypted email
capabilities in Mozilla email clients (including Thunderbird) came to a 
dead end years ago.  In the years 2000-2002 there was a big effort to 
bring the SMIME capabilities in (then Mozilla 1.x) up to the then-current
standards, S/MIME 3.0 and Cryptographic Message Syntax (CMS) 1.0.  
Support was added to NSS for CMS 1, defined in RFC 2630 dated June 1999.
Support was added to Mozilla for S/MIME 3.0 RFC 2633.   Worked stopped
just short of implementing "Enhanced Security Services for S/MIME", 
defined in RFC 2634 also in June 1999.  I believe NSS is capable of 
doing it, but the Mozilla mailnews software does not do it.

Then it all stopped,  Since then, efforts have been made to fix a bug or
two here or there, and to keep it working as well as it did when changes
to the underlying code base have necessitated maintenance to this code,
but it hasn't moved forward.  

Since then, the standards for S/MIME have continue to advance, including:
1999/06 - ESS   - RFC 2634
2002/08 - CMS 2 - RFC 3369
2004/07 - CMS 3 - RFC 3852, used in S/MIME v 3.1, RFC 3851.

but none of these newer standards have been picked up in Mozilla mailnews
clients, AFAIK.  I know of no new features that have been added to Mozilla's
SMIME support since then.  

2-3 years ago, the government of France employed a team to develop 
enhancements to Mozilla's email capabilities.  They developed two 
significant patches to implement two components of ESS, attached to 
Bug 380624 - ESS: Triple Wrapping (RFC2634 - 1.1)
Bug 386313 - ESS: Signed Receipts (RFC2634 - 2)

Those patches have been sitting, awaiting review, for over 18 months now.
This says to me that, even if someone with the significant resources of a 
western nation applies those resources to enhancing the SMIME capabilities
in Mozilla mailnews, they cannot be assured that those enhancements will 
get into the product.  

I do not wish to be critical here of any particular group of Mozilla mailnews
contributors, but I will offer some observations about the current situation.

I observe that there is something of a "stalemate" between the mailnews 
developers and the PSM developers over all matters having to do with crypto
in Mozilla mailnews.  It appears to me (I can back this up by citing 
specific bugs, if necessary) that members of both groups are (or have been)
waiting for members of the other group to move forward on this.  I believe 
the PSM folks have been told pretty clearly that they are to give all 
priority to browser issues, not to mailnews issues.  I believe the mailnews
guys do not give a high priority to SMIME issues, but even if they did, they
(some of them) perceive that PSM code (and crypto code in general) is all 
rather foreign to them, and perhaps that they are not welcome to change PSM.

Even getting issues regarding the use of SSL in mailnews fixed has been very
slow and painful, witness the huge recent arguments over the utility of SSL
client authentication with mail servers, and the numerous bugs on that subject.  

I wish I could see a way out of this, but I do not.  I invite the management 
of Mozilla's mail/news company (is it called "mailco" now?) to participate 
in this discussion if they can see a way forward.  Another venue for this 
discussion would be OK, IF and only IF the mailco managers will commit to 
engaging in discussion there.  

Perhaps if someone was to fund one or more developers to work at mailco for 
the exclusive purposes of moving S/MIME forward, it would move forward again.  
To succeed, that person, or group of persons, would need the authority to 
make the changes that the French contributors did not have.
afaik, the s/mime changes are awaiting Kaie's review, and that has not gone anywhere. Perhaps we need some peers in s/mime so we're not blocked on Kaie.
Nelson - I'm happy to talk about MoMo (that's the new cool name for Mozilla Messaging) anywhere, but as you suspected this bug feels like the wrong place.  If it's to be in a bug, maybe we could have a bug that's about _that_ topic, and leave this bug to the topic in the subject?

(Aside: I've met several times with many individuals in the French government driving the Milimail project, and from what I can tell they're actually pretty happy with where Thunderbird is at.  I don't recall whether we talked about those paches in particular, but in general their needs are better met by developing a comprehensive add-on which does a lot more -- used to be called milimail, now called trustedbird).

I think I share part of the assessment that there's not the right level of code evolution in the security-related code that impacts Thunderbird, either in PSM or NSS, from what I can tell.  I suspect part of that is because NSS is used in lots of products (and so many of the interfaces aren't XPCOM, IIRC), and neither NSS nor PSM have enough people working on them given the complexity of the issues.  Another big reason I suspect is that changing security-related code is scary, so it's hard to get new people into it.  

I've done a little digging into PSM/NSS to try and provide interfaces to cert errors that are more user-friendly in an email context than the current browser-centric scenarios, and that code is no fun.  Also, figuring out how to evolve new interfaces to that code while not introducing security risk for products (like Firefox) that may not need them will take serious module ownership, planning, architecture, etc.

A different problem is how to assess the value of pushing s/mime forward relative to all the other things we could/should be doing from a Thunderbird specific POV.  At this point, I can't see having an s/mime specific engineer, given that we have a handful of people, and lots of areas to improve that affect large percentages of our user base, unlike s/mime (which, AFAICT, is important for a small % of users).  I am super motivated to do what I can to get good contributions from qualified third parties, though!
[Off-Topic]

David A., there has been also some discussion at m.d.t.crypto and m.d.s.policy on how to advance S/MIME. I suggest to read recent threads and join for some initial discussion. The goals are to make it relevant for many % of users ;-)

Fixing this bug would be also helpful for some users. However I'm not sure of Kai can take any more...Thanks.
In reply to comment 15:
MoMo, eh?  Cute.  I like it.
MoMe might fit the words better, but probably would be pronounced mommy :)

Regarding PSM staffing:  For a long time, PSM staff was Kai and Kai alone.  
Kai did (does) a good job but there is just too much to do.  So, back when 
MoCo announced it was putting its emphasis on Firefox, Kai's (then) boss 
told me that he had directed Kai to give all priority to FF, so that his 
efforts would be aligned with MoCo's.  I think that's more-or-less the same 
today.  Maybe MoMo should ask Kai's present boss at Red Hat if they're 
willing to contribute more to TB, now that MoMo is is business (so to speak). 

Recently, MoCo added Honza Bombas to the PSM team!  Honza is also very capable.  Maybe MoCo could lend some of his time to reviewing the bugs cited above, and/or other MoMo work for SMIME and/or mail-over-SSL/TLS.  

I think the milimail patches need some more work.  I think the Milimail folks
have long ago given up on trying to get their changes into Firefox, and so 
now they probably won't be quick to pick that back up, but they've done MOST
of the work, IMO, and what's left is some UI polishing and some new prefs, 
IMO.  It would be good if MoMo could lend a hand with that.  

The patch for triple wrapping is predominately in 
mozilla/mail/extensions
mozilla/mail/themes and
mozilla/mailnews/extensions/smime/resources/content,
and it's not immediately clear to me that any of that is rightfully PSM.  
Only two files, in mozilla/mailnews/extensions/smime/src, appear to be 
c++ code.  The rest is Xul, js, css and property strings.

IMO, the area where attention is MOST needed is straightening out the whole
mess of certificate preference selection on a per-account basis, so that the 
right cert (which may be NO cert) gets used consistently for IMAP or SMTP or 
POP over SSL/TLS, based on account prefs, without needing to pester the user 
constantly.  (Sorry, that's not good news for this bug, but it's gotten a 
WHOLE lot more attention from users than this one has, IMO.  Squeaky wheel
should get SOME grease.)

I will volunteer to help any MoMo developer with any scary stuff as best I can
including suggesting possible changes to the PSM components (or whatever they really are).  After 13 years, none of this stuff scares me any more. :)

In reply to comment 16:
The discussion in m.d.t.crypto is buried pretty deep in another thread, IIRC.
I would characterize it more as a discussion of how non-software developers
would redesign SMIME than how to advance it.  Considering how active the 
IETF SMIME WG is (quite), I think MoMo should try to keep up with the pack
rather than going off inventing something totally new.
IN the last 3.25 years, the NSS team has made these changes to the relevant
NSS code for SMIME:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=NSS&branch=&branchtype=match&dir=mozilla%2Fsecurity%2Fnss%2Flib%2Fsmime&file=&filetype=regexp&who=&whotype=regexp&sortby=Date&hours=2&date=explicit&mindate=2006-01-01&maxdate=2010-01-01&cvsroot=%2Fcvsroot

That's not a lot of code.  The highlights are:
a) Added support for AES encryption (bug 379753)
b) Added support for generalized PKCS#5 v2 Password Based Encryption 
   (Bug 401928)
c) Work around a flaw in messages received from KMail (Bug 379625)
It would be useful to allow saving an encrypted email message in the clear (on a local or network folder).  If a file needs to be protected once it is decrypted, there are other less problematic ways to do it.  

Anything we can do to push this project up to the top of the list of things to "fix"?
I agree with the sediments in message #3 & #10. It would seem to be fairly easy to give the end user a prompt to save a message that was just decrypted and is currently displayed on the screen. Just give 'em the ability to save the message in a decrypted form since the difficult part of decrypting is already done. Now I just want to save the message so if my key changes I don't have to keep the old key around to decrypt the messages every time I want to view them. I want the messages encrypted for transmission I don't need them encrypted once they arrive. But by making it a prompt when you open/close the message or a check box item in the configuration you give the end user the choice as to how they want to store their email.
as stated in Bug 276786, I agree with nelson's comment 6 that secure by default (i.e. keep the local data encrypted if we get it that way from transport) is the right approach, but that one should offer options for different behaviour of one's mail client:
1) In a message-detail's "save as" add the option to save unencrypted
2) by default keep the subject/from decrypted (once there is smime-v3) to have at least in the inbox the overview who sent what (trigger the decryption by the first view by the user)
3) after first view, also keep the body decrypted (to allow for full-text searching)
4) after first view, keep the entire message decrypted (incl. attachments)
Worth to mention: 
    the right key management policy *mandates* you to securely destroy the expired private keys.

Indeed, do you keep expired "your certificates" in PSM? I believe, you don't. So, if you didn't manage to manually save your decrypted mail somewhere by copy-paste (sic!) from a mail window, it lost forever :( This is quite annoying and error-prone.
I keep my expired certificates for the reason you suggest.  I also keep all of my email, but all the storage used by Firefox to hold the email, profiles, etc., is in encrypted O/S files.  (Windows XP Professional). 

IMO the fact that messages are stored encrypted is one of the main reasons why I do not use email routinely when communicating to other people with MIME keys. I would not recommend use of MIME to my friends for this reason.  If decryption were automatic when arriving at the user agent then email encryption could be automatic in these cases.  Users would have a once a year hassle updating their browser keys and would have to take care not to send a private message to a person who didn't have encryption, but otherwise operation would be automatic.

It continues to amaze me that after all of these years people are still handling email encryption incorrectly from the human factors standpoint, and hence the result is NO encryption and No security.
PSM DOES NOT automatically delete expired certs in any category.  
It is always possible to read old encrypted emails because PSM 
does not delete either the old certs nor the old private keys.
(In reply to comment #25)
> PSM DOES NOT automatically delete expired certs in any category.  

That's rigth. But if you keep expired "your certs", that's wrong.

The true key management policy/rules, if you have one, obliges you to irreversibly erase expired private keys. 

This is important, because keys can be stolen. An adversary can use stolen keys to read enciphered messages, intercepted in the past. And, if cert key usage also allows signing (typical Verisign/Thawte/etc certs allow), an adversary can forge your signature post factum.
It is MUCH easier for your adversary to steal messages that have been 
decrypted and stored as plaintext than to steal your private keys and 
re-decrypt your encrypted messages.
It depends.

Assume I do not keep highly sensitive mail at all. I receive sensitive mail, read, take into account, and erase immediately. But adversary - intercepts and saves. Doesn't delete.

So, my mailbox is really secure, there is no sensitive mail in. Impossible to steal. But, once upon a time a bunch of my expired private keys get stolen. Bingo! An adversary reads accumulated sensitive messages.

That's why the keys shall be deleted as soon as they expire.

At the same time, I can choose to keep not very sensitive, but for some reason encrypted messages in my mailbox. I do not want to loose access to these messages after erasing private keys.

Then, stealing from a mailbox and stealing private keys - are different tasks. There may be an opportunity to steal keys, but may not be an opportunity to steal from a mailbox.
(In reply to comment #28)
> Assume I do not keep highly sensitive mail at all. I receive sensitive mail,
> read, take into account, and erase immediately. But adversary - intercepts and
> saves. Doesn't delete.
> 
> So, my mailbox is really secure, there is no sensitive mail in. Impossible to
> steal.
I guess you are assuming that no traces are left.

> That's why the keys shall be deleted as soon as they expire.
Implying that they can be reliable deleted.

> 
> Then, stealing from a mailbox and stealing private keys - are different tasks.
> There may be an opportunity to steal keys, but may not be an opportunity to
> steal from a mailbox.
And the other way round. You might want to protect both.
Generally speaking, if one wants to have a somewhat reliable protection of sensitive information on his machine he should use full disk encryption or such, ie. have most non-volatile memory encrypted, which in this case should at least include the private key storage, the mail storage and any swap partitions/files.

That's why I am not against saving mails unencrypted (unencrypted from TB's POV).
Blocks: 644723
Almost ten years and not the SLIGHTEST progress. Oh well...
Reminds me of Outlook Express and its forever unresolved bugs that used to drive everyone nuts (until everyone stopped using it of course).

Any hints for a replacement for Thunderbird that will allow me to actually WORK with my email archives are very welcome.
I just wanted to bring this topic up again. I think that's one of the most needed feature at the moment.

In the pre-snowden-era people mostly used email encryption in single cases, e.g. if they had a secret information to send to someone else. Back then the argument to better have it stored encrypted made sense (see above). 

But now many people want to use encrypted emails on a daily basis. They want to encrypt not because they have a secret but to prevent someone, e.g. NSA, to build a lifetime archive of their communication. 

In this new use case searching emails and storing them decrypted is essential. Otherwise it would turn a nightmare! Think of just 5 months of email and you need to search for one. Think of ten years of emails - you will not even be able to remember all you different keys and passwords.
(In reply to O. Furlong from comment #31)
Dear developers, I agree fully with Mr Furlong, and hope sb finds the passion to prioritize this bug.

Recent developments show us how importent encryption is and its widespread use is dependant on easy usability.
Local encryption can be omitted without big losses in security but great improvements for the usability in this case. Anyway quite a few people use transparent full disc encryption anyway.
I guess, the lack of development resources is not the main obstacle to have this issue resolved. Look, even if I decrypt a message, I do not want to discard encrypted one, because it contains, in general, correspondent's signature and certificate, s/mime caps, etc. I want to keep encrypted message as long as decrypted one. That is, encrypted and decrypted messages are the pair.

How may this fit into the very common use case of [IMAP + server-side search] ? There must be some rule, how both parts of message pair are kept on the server. Possible choices include:

  1) advance IMAP standard :) to be able to track related versions of a message
  2) keep encrypted message as attachment to decrypted one
  3) replace encrypted message by decrypted one, but put encrypted into distinct IMAP subfolder
  4) keep both parts of pair in the same IMAP folder, but track relation by message headers
  ...

(1) is hopeless choice, (2-...) aren't interoperable. An individual developer wouldn't take a risk to implement any of non-interoperable choices, because of high probability of being not approved by Mozilla team. The broad discussion is required before some progress could be made in this issue.
I understand the issues with IMAP and appreciate your ideas of keeping a encrypted copy. So my suggestion:

1. First make a option to overwrite encrypted email with decrypted one using POP3. Implement feature to keep a encrypted copy in a specified folder 
2. Then try to solve the issues with IMAP. Here I suggest to start with an option to store decrypted emails locally, then implement one of the ideas for changing them on the server (comment #33).
Ok, I will not give up until this this bug is solved. So I will do a crowdfunding. But I need your help:
1. Is there a thunderbird developer who can estimate the costs of the simplest solution (= pop3 mode and overwrite existing mails with decrypted content)
2. Is there a freelance developer willing to do that for money in the next months?
3. Ideas for a suitable crowdfunding platform? 
4. Are there any other wishes/ideas?
This is a great initiative. Thank you.
This is how this can be implemented:

New check box on: Tools -> Account Settings -> <account@name> -> Security 

   [x] Create decrypted copy

and button:

   [Remove decrypted copies]

If option is checked then (as soon as you decrypt mail) Thunderbird will:

   a) Put original encrypted mail into separate field for backup purposes.
   b) Replace current encrypted mail with decrypted copy.

If you press [Remove decrypted copies] button then Thunderbird simply restores encrypted mail from the backup. Note: Before restoring encrypted copy, Thunderbird can warn users about missing private certificates - emails which could not be decrypted any more.

I agree that main thing is to protect e-mail while it is travelling trough the Internet. As soon as e-mail safely arrives into protected environment, it can be stored in plain format.
Here is a first draft of the feature request. I tried to keep it as minimal as possible: 
http://pastebin.com/3P8uXfFs

Feel free to comment! We will start a crowdfunding for it soon. 

- Imap support was skipped, could be done in a second funding though
- Added request for keeping encrypted copy, so original headers and/or digital signatures are preserved
- Removing button is not needed, as user can delete decrypted mails by himself and still has copy in encryption folder
- We're trying to enable enigmail programer Patrick Brunschwig to implement GnuPG option with this request also
Again, great initiative.

In my view, support for permanenet LOCAL decryption and storage would be perfectly sufficient, for a start.

If needed, one could always set up a filter action that moves decrypted copies back to the IMAP server.
Addendum: 

A first solution should not be limited to POP _retrieval_. For example in Thunderbird, I only use IMAP access with all mail accounts, but then have Thunderbird copy new mail to local mail folders (based on automatic filter actions). 

Thus the following scenario should be covered as well:

- retrieve mails in Thunderbird via IMAP,
- decrypt them locally (leaving the copy on the IMAP server untouched/encrypted)
- move decrypted copy to local Thunderbird mail folder (e.g. using mail filters)

Cheers David.P
#40: Just tried it: You can create an IMAP and POP3 account for the same mailbox - so you can easily use the POP3 decrypting solution parallel to an IMAP account.
I know (and have done that for years) but it is much more complicated to fetch mail using both IMAP and POP, and can have unwanted side-effects, depending on the IMAP service.

I'd rather use only IMAP everywhere, and then handle and store (only) those encrypted messages locally.

The local (client) handling, decryption and storage *after* the transfer is the crucial issue in my opinion.

Thus, the solution should not be limited to one of POP and IMAP access (since this again only _transfers_ the mail from the server to the client), but instead should be independent of that transfer mode.
Ok, I just had a nice idea from your suggestion: Probably it's even easier and more powerful to implement a decryption action for the filter dialog. 

"decrypt message"

You can combine that with copy and move:
"copy message to" "encrypted"
"decrypt message"

What do you others think?
YESSSSS.

A great idea, for its clarity, simplicity, and flexibility.

This would be THE ideal starting point for a first (and possible even final) solution regarding the present issue, in my view.
I do have an encrypted hard drive with pretty catholic file system permissions. Anyway, I prefer my encrypted mail to stay as it is. Why? Glad you ask. Once adversaries get wind of Thunderbird's storing encrypted mail decrypted they will switch from intercepting transport to scanning your mail folders with malware. Bam! Precautions subverted. And while we're at it, why not abandon the master password and store all login data in the clear?

Long story short, a serious MUA must be capable of searching encrypted mail without storing the cleartext.

As a side note, one popular mistake made by people who say there is "no sensitive mail in my mailbox" is that it's not themselves who decide what is sensitive, it's the adversaries.
Wrong, with malware on your system you already lost. (And the master password is just protecting against casual password reveal, it's no protection if someone puts any effort into it.)
Finally! We just started a crowd funding for the filter action solution. Any programmers are welcome to work on it.
If everybody just gives a small amount we can fulfill this ten year old request! 

http://freedomsponsors.org/core/issue/434/encrypted-email-messages-should-be-stored-decrypted-in-the-local-folders
I'd love to push this initiative financially, but I'm confused of there being two crowdfunding campaigns (http://freedomsponsors.org/core/issue/435/decrypt-messages-permanently and http://freedomsponsors.org/core/issue/434/encrypted-email-messages-should-be-stored-decrypted-in-the-local-folders).

Are those two campaigns on competition and would each of them lead to a working solution, regardless of the other one? Or are both required and should I consequentially support both?

It would be great if somebody could clarify ...
#48: Fine!

We had to split it, as there are mainly two encryption technologies in use: 
- The Thunderbird campaign (434, second link) implements it for the built-in S/MIME encryption 
- The Enigmail campaign (435, first link) implements it for the popular add-on which offers OpenPGP-encryption.

As they are written in different languages on different repositories, it didn't make sense to fund them together. So you only need one, depending which encryption you use currently.
Well, if it's democratically agreed to do it the wrong way I'm totally fine with that. Just don't blame me afterwards for not having informed you thusly when all falls to pieces.
You will retain the option to keep encrypted mail encrypted on your hard drive.  However, if you don't enable this option, you need to remember that doing so means that you are probably likely to keep your old encryption keys lying around so you can read your own old mail. This will make things less secure for any messages that you decided to delete, since any wiretapper will be able to decode old stored messages should they overrun your computer.

I found that the lack of this feature made using encrypted email impractical. So much so, that I was one of the original people to request this feature. It wasn't until Snowden came along that people started taking this issue seriously.  (In my cynical moments I thought perhaps the NSA had contributed to the delay of this capability. For all I know they may still be contributing FUD to this very thread.)
Hello Everybody,

I have read this post and a couple related or similar bug posts and I thought maybe I can work on this bug. Before I start to work, I just wanted to ask if there is any progress?
Feel free to work on it!
Guys I need help! Since we need to store mails decrypted, we need to find which function makes the decryption process. I've searched the source files of TB but I couldn't locate proper codes doing decryption. If you know something about this, then your help is needed!
Thanks to Janosch Rux, Patrick Brunschwig and others a filter rule to decrypt messages permanently was added to Enigmail. Maybe that solves this bug here?

http://sourceforge.net/p/enigmail/bugs/1/
https://www.enigmail.net/download/changelog.php#enig1.8

Thank you so much!
Yes, I think so. The filter rules actually also work for S/MIME.
Late to comment on this.  I recently submitted a bug/request going the other way in regards copies of sent mail that are now saved in clear text (I feel that at the least there should be the option to save the local copy encrypted with the users smime cert) 

But I do agree with comments suggesting giving the user the option to save messages decrypted in a local folder is benefitial - it is their mail afterall. 

BTW - For those who use smartcards with pinpads, malware is not an issue (comments 45 and 46)

I completely agree with the original post.
Mail encryption should be only for transport in the first place. Security of local stored data is an issue for itself.
Mails should be locally stored unencrypted.
So You can search in them, and do not need to bother about lost / invalid private keys.

I know there is a filter possibility in Enigmail, but I would like to have a global option: "Store decrypted mails unencrypted".

This very reduces complexity and possible loss of data for users that have not much knowledge of keys/encryption, and even for myself, who has some good knowledge of keys/encryption.

Please aasign this bug to category
MailNews Core -> Security: OpenPGP

Filed a clone of this bug in MailNews Core -> Security: OpenPGP
as now OpenPGP is developed in Thunderbird.
Clone Bug: #1638569

Since there is no auto linking, here the link to the bug clone: bug 1638569

This bug is not about OpenPGP, but about encrypted messages in general. I.e. it affects both S/MIME and OpenPGP. And in my eyes it needs to be solved generically, and not (only) specifically for OpenPGP.

No need for a duplicate. To autolink, just type "bug" followed by the number.

I think the way we'd do this is that we let you set up a filter to do what you want.

Component: General → Filters

I am glad that this bug is aware of and would be happy if there would continue some deeper thinking about this.
See also RfC 7435 "Opportunistic Security: Some Protection Most of the Time" https://tools.ietf.org/html/rfc7435

Let's reassign component to OpenPGP, as that's what we're currently working on, and to have it on the radar.

Component: Filters → Security: OpenPGP
Product: Thunderbird → MailNews Core
Blocks: 188988, glodafailtracker
See Also: → 1562737
Whiteboard: [datalossy]

(In reply to Kai Engert (:KaiE:) from comment #67)

Let's reassign component to OpenPGP, as that's what we're currently working on, and to have it on the radar.

And what of those using S/MIME?

No longer blocks: 188988

In Topicbox was named the use case of an external mail archive:
"[...] option for storing decrypted mails permanently in TB's folders.
It is very useful, if mails are archieved later on with external mail archivers, for example MailStore or Copernic Desktop Search. Content in those archives can be searched very comfortably."
(in addition to comment 3)

Per comment 65, I think filters to (permanently) decrypt would be the solution here - bug 1627962.
Filters would mean the user actively opts in to the feature, and they can choose where the decrypted messages are put.

Depends on: 1627962

Filters may be tricky to implement. Suppose two actions: Decrypt message + Archive, where archive goes to the archives of local folders. It should not first decrypt the message on the IMAP server and then archive to the local folders. It neither will work if done by hand: decrypt and then archive (or move).

It makes more sense to define certain destinations (servers, folders) as clear-text destinations. Whenever a message is moved there (via archive, with filters or manually), decryption is attempted. It should still be off by default, of course, so the user has to opt-in.

Of course the filter action should not first decrypt then move, but we could have an action "archive as unencrypted" or similar.
Many people will have different opinions on exactly the want the emails handled (or not handled at all), so that's why I think filters provide the flexibility we need.

That may be an option, together with "move as clear text", "copy as clear text", etc.

It is not a solution for manual actions, unless all these actions are also added to the message menus.

Defining destinations (servers and/or folders) as clear text destinations is much simpler: the user chooses which folders it trusts. It still requires user intervention, because by default there are no clear text destinations. It is less flexible in the sense that everything that is moved there would be decrypted, which is perhaps not desirable.

I want to build on Nelson's last sentence in comment 6; in my opinion, the general question is:

"Should Thunderbird canonicalize incoming messages' format (while conserving their content as seen by the users), or rather, maintain authentic originals?"

In this vein we would potentially look at:

  • decryption
  • decoding base64, quoted-printable etc.
  • (fixing character set encoding errors a-la-BiDi Mail UI)
  • making everything UTF-8
  • Transitioning from a MIME structure to some equivalent in whatever message storing backend TB uses

Personally I am of two minds about this. Canonicalization obviously should certainly improve performance and searchability (that is, if we ever get to properly redoing the core message-handling code and mime library). But not being able to reproduce, byte-by-byte, the message one got is also a problem. Then again - every SMTP hop can changes the message somewhat.

I guess I would say that this needs to be an option, for users to decide between. Particularly w.r.t. decryption.

What I don't buy is the security argument. Don't avoid decrypted-storage because of security concerns.

Moving locally stored decrypted messages to another mail account should re-encrypt them with the destination account's PGP key (if one is configured) before uploading them to the server.

See Also: → 1693332

Just to clarify, I believe it's a bad idea to store emails decrypted in local folders but moving messages between accounts should re-encrypt them to the destination account's key and decrypt them if there is no destination account key.

Accounts with PGP configured should store the messages encrypted.

comment #77 is Spam. It does not make sense. It's main purpose seems to be to promote some commercial mail services. The authoring account was only created for that post. Wondering why it has not been deleted yet.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.