The hallmark of a small mind is to answer the question "How do I do XYZZY" with "Why would you want to do that?". In the case below, I am forwarding a copy of the message to a friend of mine for safe keeping. I don't want him to read it, just keep it safe.
The immediate solution might be to save the encrypted file entact somehow, then 'zip' it to protect it from Netscape/Mozilla as an attachment. But when those kludges become the standard, we all lose. But the real frustration I have seen for the last 20 years is that designers have one mode of operation in mind, and can't fathom that other people can have better (different) ideas or uses. If the new addressee is an alias for the actual original recipient, then they will have the needed keys, if not they won't (*Not your problem*). But don't restrict distribution because the designer didn't think about entities sharing keys. Leave that problem for the user. This "working exactly as it should" seems to be an Ollie North program. " I know what my boss really wants and so I will do that as well". Simply do the assigned task and no more! "I want to forward a copy of this file to Bill...do it". Andrew Bashere Andrew Perry wrote: > This appears to be working exactly as it should. > > 1. You wish to FORWARD a message to someone. This means that the > destination address MAY BE DIFFERENT which requires that a new Public > Key be used for the encryption. It matters not that you are sending the > email to the same original recipient. Netscape must still decrypt the > message and re-encrypt it with the NEW destination address certificate. > NOTE: You would NOT want Netscape to send messages to Recipient B > using Recipient A's public key !!! > > 2. Allow me to paraphrase ... "If I remove the checks for .... encrypt, > it wants to send the new message .... unencrypted!" > Um ... well ... Yeah ?!? > > Andrew > > Nelson B. Bolyard wrote: > >> I just discovered a NASTY problem with S/MIME in Communicator 4.7x. >> I certainly hope Mozilla's S/MIME will get this right. >> >> 8 days ago, I sent a signed and encrypted email to someone. After he >> received it, he had a hard disk crash, and lost his email folders. >> Fortunately, his private keys and certs were backed up. >> >> So, he got a new disk, reinstalled everything, and wrote me asking me >> to resend that signed and encrypted message to him. I have a copy of >> the signed and encrypted message in my folder of sent messages. I >> don't want to make a new signed and encrypted message from the >> plaintext of the >> original. I just want to forward an exact copy of the original encrypted >> message to him. >> >> NO CAN DO. >> >> Communicator wants my private key to forward the message. >> I shouldn't need my private key to forward an exact copy of the original >> signed-and-encrypted email. It should be forwarded exactly as is. >> Right? >> >> Nope. Communicator won't forward it. Without my private key, >> Communicator only forwards the original message header (which wasn't >> encrypted in the >> original message) with no body. >> If I login to my crypto token, unlocking my private key, then >> Communicator can read the decrypted original message. But then what >> it does is not forward the original signed-and-encrypted message >> as-is. Instead it creates a new message, which has the decrypted >> original plaintext message as an attachment, and it wants to sign and >> encrypt that new message. >> If I remove the checks for the checkboxes for sign and encrypt, it >> wants to send the new message, with the decrypted original plaintext >> message attached, unencrypted! >> I certainly hope Mozilla's S/MIME will get this right. >> >> -- >> Nelson Bolyard >> >
