encrypt email with multiple recipients with gpg

Have support for public servers activated. Turn on GPG suppo

Sat, 24 Sep 2005 08:55:55 +0000

Have support for public servers activated. Turn on GPG support and import your own public and private keys. (It makes no difference whether you have any public key in your address book.) Then, write an email to a third person and let IMP encrypt it. Now comes the bug: The email is encrypted with your public key and not with the recevier's public key! (The latter were correct.) If he recevied this email, he cannot decrypt it. Possible resolutions: - Let IMP fetch the public key from public servers. - Get the key from address-book entries (gpg will possibly complain about you cannot trust this key, but it should work) - Refuse to cypher this email, because you don't have the right key.

Issue still exists even If you have public keys in your addr

Sat, 24 Sep 2005 09:38:22 +0000

Issue still exists even If you have public keys in your address-book and assigned a default address book to IMP. (See ticket #2671 for latter.) The email should be encrypted for every of the receivers and the sender or fail. ('And' has precedence.) ("Verschränkte Verschlüsselung.")

> Now comes the bug: > The email is encrypted with your pub

Tue, 27 Sep 2005 07:00:00 +0000

> Now comes the bug: > The email is encrypted with your public key and not with the > recevier's public key! (The latter were correct.) If he recevied this > email, he cannot decrypt it. I don't think so. All sorts of people (including me) have been able to send encrypted mail to third party users without any problems for years now. > Possible resolutions: > - Let IMP fetch the public key from public servers. > - Get the key from address-book entries (gpg will possibly complain > about you cannot trust this key, but it should work) > - Refuse to cypher this email, because you don't have the right key. ... and this is exactly what we do. Are you confusing the message you are sending out with any message that is saved in your sent-mail folder? Because of course those messages aren't the same.

>> [...] If he recevied this email, he cannot decrypt it. >

Tue, 27 Sep 2005 10:38:19 +0000

>> [...] If he recevied this email, he cannot decrypt it. > > I don't think so. All sorts of people (including me) have been able > to send encrypted mail to third party users without any problems for > years now. That goes for me, too. But I've not been using IMP but other email clients. Before anyone could read my IMP-encrypted emails I've cancelled their further processing due to the wring encryption. >> Possible resolutions: >> [...] > ... and this is exactly what we do. Are you confusing the message > you are sending out with any message that is saved in your sent-mail > folder? Because of course those messages aren't the same. Does this mean, my message and it's copy are not the same? Very strange. Yes, I've always assumed original and copy will be the same - even encrypted ones. I will check the entire process again, but the encryption-process will be still not correct - at least due to this fact.

Okay, this is how obviously IMP encrypts emails: - For ever

Tue, 27 Sep 2005 14:56:55 +0000

Okay, this is how obviously IMP encrypts emails: - For every recipient individually with his/hers public key. - For 'me' as sender, to be put in thr outgoing-folder. This is how it should IMHO be done: - Encrypt the email with multiple public keys of the recipients and optionally the sender. (Verschränkte Verschlüsselung; kombinacja kluczy publicznych.) That (one) email goes to the recipients and as copy to my folder. By this you get a real and authentic copy and IMP is not vulnerable to "DOS-emails": - Create an email to be encrypted with the largest possible attachment. - Give it a lot of people with certificates as recipients (i.e. all the Gentoo developers). - Make more emails. - Send them at once. Now the load on server will raise quadratically: With every recipient and every send message. The other way it would just increase linearly with every email. (Maybe RLIMITs of Apache will prevent this. Does max_execution_time help?) I hope I am wrong.

This is not a bug - rather an enhancement. The issue was th

Thu, 29 Sep 2005 04:31:00 +0000

This is not a bug - rather an enhancement. The issue was that the gnupg documentation was not clear at all that it supported multiple recipient encryption on the command line. multiple recipient encryption has been implemented in Horde HEAD and IMP HEAD. please test and give feedback.

> multiple recipient encryption has been implemented in Hord

Thu, 29 Sep 2005 21:01:05 +0000

> multiple recipient encryption has been implemented in Horde HEAD and > IMP HEAD. please test and give feedback. I am currently not able to get these versions up and running. Please expect my feedback these days.

no further feedback. this will not be backported since it r

Fri, 07 Oct 2005 05:38:28 +0000

no further feedback. this will not be backported since it requires horde 3.1.

Sorry, I did not manage to get the latest HEAD snapshot of H

Fri, 07 Oct 2005 20:33:18 +0000

Sorry, I did not manage to get the latest HEAD snapshot of Horde and Imp running. The bug still persists in the latest FRAMEWORK snapshot. (Latest means: 2005-10-07)

As stated previously, this is not going to be backported to

Fri, 07 Oct 2005 20:47:00 +0000

As stated previously, this is not going to be backported to the framework (e.g. IMP 4.0.x) version. This decision was made because 1) it requires a version of Horde that doesn't exist yet and 2) this is an enhancement request, not a bug (i.e. sending messages to multiple recipients works fine now, it just works better after the changes).

Changes have been made in Git (master): commit 28e2ec8a9913

Wed, 06 Sep 2017 08:17:13 +0000

Changes have been made in Git (master): commit 28e2ec8a9913c8f4404fbb2e3a9de6890a696089 Author: Paul M Jones Date: Wed Nov 3 15:24:00 2004 +0000 fixed bug 2670, new links now get 'css_new' class (not 'css' normal class) git-svn-id: https://svn.php.net/repository/pear/packages/Text_Wiki/trunk@172022 c90b9560-bf6c-de11-be94-00142212c4b1 Text/Wiki/Render/Xhtml/Wikilink.php | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) http://github.com/horde/horde/commit/28e2ec8a9913c8f4404fbb2e3a9de6890a696089