Changes have been made in Git (master):

commit 28e2ec8a9913c8f4404fbb2e3a9de6890a696089
Author: Paul M Jones <pmjones@ciaweb.net>
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

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).

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)

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

I am currently not able to get these versions up and running.

Please expect my feedback these days.

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.

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.

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.
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.

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.
... 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.

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.")

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.