The Basic answer to both of these questions is:
1) The system is functioning as designed. -- and --
2) The design does not allow a legitimate function to happen.
The forward code *purposefully* decodes and re-encodes the email
message. This is because (as pointed out) the most common case of
forwarding is the desired recipients are almost always different from
initial recipients, which may mean not only a change in private keys,
but also a change in the encryption standard itself. Ironically while
this makes sense to the novice user, who would be confused when he
forwards a message he can read but his recipient can't, the advanced
user is quite surprised at the fact that he can't just send this binary
blob to whoever and let them deal with decrypting. I myself have ran
into this, even though I know it's not the normal usage.
Around this whole forwarding scheme, there are lots of different
semantics we could, and should, support. One would like the ability to
make a message so that it doesn't accidently reduce it's security
because someone forwarded (become decrypted on the wire). It would be
nice to just add the new recipients to the recipient list without
encrypting the whole message if possible. It would be nice to notice
that you are simply resending on old message, and mess with it at all.
Even better, it would be nice to at least give users the option of
forwarding encrypted mail even if they can't decrypt it (after the
appropriate approvals).
I'm pretty sure none of this will be in Netscape 6.2, where the goal is
simply to get back to parity with Communicator in S/Mime support.
bob
