store encrypted emails with the user's gpg key

[apm256]

It seems to be impossible, for the moment, to read a sent encrypted email. It would be great to store it with our own gpg key instead of the addressee's.

[pazz]

So far, alot stores exactly what it sent out, this is correct. Could you research a little as to how this is done in other clients (mutt/notmuch-emacs)? One solution is to simply always additionally encrypt for you own public key...

[apm256]

Thanks for the precision. OK, I will investigate the way it is done in other clients.

[apm256]

from Jameson Graef Rollins, on the notmuch mailing-list:

You do not need to change alot, just notmuch emacs also doesn't need to do anything special to allow for this. Just add an

 encrypt-to <keyid>

line to your ~/.gnupg/gpg.conf, where is your personal keyid. Then all encrypted data is also encrypted to your personal key, making it always viewable by you as well. Then you can just open your encrypted sent mail as you would any other encrypted mail.

[pazz]

Quoting apm256 (2013-11-18 08:45:39)

from Jameson Graef Rollins, on the notmuch mailing-list:

 You do not need to change alot, just notmuch emacs also doesn't need to
 do anything special to allow for this. Just add an

encrypt-to

 line to your ~/.gnupg/gpg.conf, where is your personal keyid. Then
 all encrypted data is also encrypted to your personal key, making it
 always
 viewable by you as well. Then you can just open your encrypted sent mail
 as you would any other encrypted mail.

Yes, I saw that mail, but thanks for replicating it here. I guess this leaves us to update the docs/FAQ for alot so that we can later point to that if someone raises the question again :)

[lucc]

It seems to me that one has to specify the correct sub key in the gpg.conf file when using the encrypt-to option. Using the id of the "parent" key resulted in an error in alot.

[lamarpavel]

I have identified a problem with the current approach:

I have two identities: Anderson and Neo, both have their own key but in the gpg.conf the encrypt-to key is set to Neo. Now I am sending a mail as Anderson to Smith, signing as Anderson and encrypting to Smith, who is under no circumstances to know of my other identity Neo. However, the mail constructed by alot will be encrypted to Smith and Neo.

There are two ways to solve this as far as I can see:

1. Don't send and store the exact same mail, allow storing modified versions (eg. encrypted to different keys)
2. Add an encrypt-to option per user account instead of relying on the gpg.conf

[pazz]

Quoting lamarpavel (2016-09-24 11:55:55)

I have identified a problem with the current approach:

I have two identities: Anderson and Neo, both have their own key but in the gpg.conf the encrypt-to key is set to Neo. Now I am sending a mail as Anderson to Smith, signing as Anderson and encrypting to Smith, who is under no circumstances to know of my other identity Neo. However, the mail constructed by alot will be encrypted to Smith and Neo.

There are two ways to solve this as far as I can see:

 1. Don't send and store the exact same mail, allow storing modified versions (eg. encrypted to different keys)  2. Add an encrypt-to option per user account instead of relying on the gpg.conf

The second option seems sensible to me as well.

[meskio]

I agree the second option sounds better than the first. I personally don't see it as high prio, as I think the sensible thing to do to have several identities that should not be related will be to use different users in the machine. But I think will be a nice feature if someone takes the time to implement it.

[lamarpavel]

@meskio There is another use case, which might be relevant to more people: Using gnupg for more than E-Mails. If, for example, you are using pass1 to encrypt your passwords and you are using an extra GPG-key for that, which is not linked to your publicly known GPG-key for E-Mails, then you don't want to auto-encrypt everything to either of those keys. I think we, as a broader community, should encourage the use of GPG for different purposes. In that light it is very inelegant to rely on the GPG config for a feature in alot.