Subject: Re: The subject line leakage problem

From: "Housley, Russ" <[email-masked]>
Date: Thu, 27 Dec 2001 10:38:09 -0500

Ned:

It seems that message/rfc822 is used to encapsulate an entire message.  In 
this case, we want to repeat a subset of the RFC 822 header lines from the 
current message, and we never want to duplicate the body.

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?

Russ

At 06:39 PM 12/21/2001 -0800, you wrote:

>>This is getting much more complicated than it needs to be, and is
>>likely to break interoperability with non-enhanced clients.
>
>>The simplest thing to do is to say:
>>- Senders should put the minimum that they want in the unprotected headers
>>- Senders include as much as they want protected in a
>>text/rfc822-header part at the beginning of a multipart/mixed message
>>- Enhanced clients should display the message with the headers from
>>the text/rfc822-header part moved to where the user thinks he/she
>>sees the headers. In the case of headers that are in both in the 822
>>message and in the text/rfc822-header body part, the latter wins
>>(because it is protected)
>
>Even simpler than this is to use message/rfc822. It has the advantage that
>conformant MUAs are supposed to handle it. There is no such requirement for
>text/rfc822-header.
>
>>- The moved-up headers may cause side-effects that the MUA should act
>>on. For example, if the Cc: in the 822 headers is "[email-masked]"
>>but the Cc: in the protected headers is "[email-masked]", the "reply
>>to all" action should include amy but not include bill.
>
>The rules for header merging from message/partial can probably be applied
>here.
>
>                                 Ned

============================================================================
================
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. 
Thank You.
============================================================================
================

---

From: [email-masked]
Date: Thu, 27 Dec 2001 09:19:14 -0800 (PST)

> 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 existing
support for message/partial and message/rfc822. It doesn't require that you add
additional fields to your structures, with all the attendant deployment
problems that will cause.

> 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 content
that it is to be merged with the outer message header on receipt. That could
easily be done with either a message-context or a content-disposition field in
the protected content.

				Ned