Freron MailMate

Comments and changes to this ticket

• 

  benny May 31st, 2018 @ 09:09 AM

  • State changed from “new” to “accepted”

  Some thoughts on this:

  1. I assume you meant “decrypted”.

  I guess there are various ways that a user might want to auto-decrypt emails. The user might even always want this to happen for the emails stored locally by MailMate (since the disk and its local backup might already be encrypted). It's a bit tricky though since these locally decrypted emails should never be uploaded to a server... Maybe MailMate could be allowed to cache a decrypted copy of each email as well as the encrypted one. That would make it safer, but it wouldn't be efficient with regard to disk storage.

  In any case, MailMate should internally be able to generate a decrypted variant of an encrypted email. This is the primary missing component for providing features related to this. I'll update this ticket if this part is ever implemented.

  If that was implemented then I'm not quite sure how to most easily allow the user to “request” the decrypted variant when e.g. dragging an email to EagleFiler or exporting in general... I'll have to give that some thought.

• You flagged this item as spam.
  

  Lars June 1st, 2018 @ 01:45 PM

  Thanks for your reply, Benny! Just as a side note on this, here's how Enigmail does it (and I have used it in the past via Thunderbird, but I feel MailMate is more reliable when handling large amounts of e-mail):

  https://www.enigmail.net/documentation/Signature_and_Encryption#Per...

  "In addition, version 1.9 added a context-menu option which can be used on the fly. Use the right mouse button on a message in the message list and select the option Decrypt to folder." (https://www.enigmail.net/index.php/en/faq?view=topic&id=15)

  Food for thought!

• 

  benny June 1st, 2018 @ 02:01 PM

  Thanks for the details. I'm not quite sure how decrypting could destroy the message as warned in the documentation, but maybe I'll realize that when/if I implement something similar :)

• You flagged this item as spam.
  

  Sebastian July 17th, 2018 @ 08:15 PM

  Dear Benny, you said "these locally decrypted emails should never be uploaded to a server". Actually, I would appreciate exactly the opposite. I trust my mail server and storing the message unencrypted on it would make my live much easier, e.g. when accessing mails via a web interface.

  Are you actively working on that feature?

• You flagged this item as spam.
  

  Lars July 17th, 2018 @ 08:21 PM

  @ Sebastian It depends on why someone is using encryption in the first place. Some people use it mainly as a precaution during transport, so while they trust their own mail server, they have messages sent to them encrypted to make sure they nobody reads them during transmission. In that case, I can see how it would greatly benefit your workflow to have them decrypted and once that has taken place to have the decrypted message replace the encrypted version on the server.

  Other people, however, use end-to-end encryption exactly because they do not trust anything other than their local machine. That means they would never want anything decrypted to leave the machine and be stored somewhere outside their control. For me, my mail server is outside my control, as it can be seized or searched without me noticing. I do have decryption mechanisms in place that allow me to use webmail on encrypted messages as well. Same goes for accessing mail on my mobile devices.

  Just for clarification, I do not want to oppose your feature request, I just wanted to point out that there are two very different ways of using encryption :-)

• 

  benny July 18th, 2018 @ 12:01 PM

  @Sebastian: No, I'm not actively working on it. When/if implemented I'll keep in mind that it should be possible to permanently decrypt incoming messages. This could e.g. happen by setting up a rule to decrypt any incoming messages, save the decrypted version in the Inbox (and uploading it), and finally deleting the encrypted original. The missing piece, again, is creating a decrypted version of an encrypted email.

  Default behavior will continue to encourage only decrypting locally.