I understand the motivation for the behavior of __attempting__ to decrypt the message, and then re-encrypt it. I don't have a problem with that.
But when the attempt fails because the local program does not have access to the necessary private key, what should the program do? Suppose that someone else, using a different S/MIME email program, (e.g. OE) succesfully forwards to me an email that I cannot read because it was not encrypted using a public key for which I possess the private key (the thing that Netscape's email tries to prevent). Should I be unable to forward that email message on, say, to someone who _might_ be able to read it? Should Netscape prevent me from attempting that for any reason? I think not. In either case, the program has a valid MIME email message, one that encapsulates something (it doesn't know what). When it cannot penetrate that encapsulation, its choices for forwarding that message are: a) forward the thing as-is, thereby doing something positive in response to the user's instructions to it, or b) (worse) fail, (say, I can't), or c) (worst) forward the thing incorrectly, forwarding only the message headers, not the encapsulated MIME message body. This is what it does. The email client will happily email PC binaries to MAC users, and vice versa. It knows how to forward MIME email messages when they're not encrypted, and/or when they contain other MIME types that are unknown to this local email client. It treats the content of the MIME message as opaque, just as it should. All I ask is that it treat endecryptable email messages as opaque messages, and forward them as it would any other email message whose content type was unknown. This request is not at odds with the goal of trying to prevent the naive user from sending something a message out that she can read but that her correspondent will be unable to read. (I don't happen to agree with that goal, but that is a digression). In this case, the user cannot herself read the encrypted message. Hence there is nothing to be lost by forwarding it as is. -- Nelson Bolyard Netscape Communications (subsidiary of AOL) Disclaimer: I speak for myself, not for Netscape
