Thanks Ned. This approach makes sense, but this is not what I thought you
meant by your first posting.
At 09:19 AM 12/27/2001 -0800, ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
It seems that message/rfc822 is used to encapsulate an entire message.
this case, we want to repeat a subset of the RFC 822 header lines from
current message, and we never want to duplicate the body.
I think this is the wrong way to go about it. If you want to protect an
entire message including its outermost headers, simply place the entire
message inside your protective envelope using the message/rfc822 construct.
Then strip the outer, unprotected header to its barest essentials.
The process is then reversed by the receiver.
This approach uses nothing but existing media types and can leverage
support for message/partial and message/rfc822. It doesn't require that
additional fields to your structures, with all the attendant deployment
problems that will cause.
The required support for message/rfc822 is attractive, but I am not sure
that is has the correct semantics. Can you explain your idea further?
See above. At most what's needed here is an indicator in the protected
that it is to be merged with the outer message header on receipt. That
easily be done with either a message-context or a content-disposition field
the protected content.
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and
CONFIDENTIAL. Access by any other party is unauthorized without the express
prior written permission of the sender. If
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender.