Subject: Re: The subject line leakage problem

From: "Housley, Russ" <[email-masked]>
Date: Tue, 18 Dec 2001 15:26:46 -0500

Jim:

I have had a lot of experience in this area, and I am glad to hear that new 
product releases have repaired this major shortcoming.  I have personally 
been bit by this by more than one product.

I do not think that MTA architectures are the main point of this thread, so 
lets see if we can get back to the S/MIME and CMS issues...

Russ

At 06:24 PM 12/18/2001 +0000, Jim Craigie wrote:
> > Now, in theory X.400 MTAs only deal with the envelope and are able to
pass
> > arbitrary content types around, making it possible to introduce new 
> ones at any
> > time. Howevr, I've found that sometimes this works in practice and often
it
> > doesn't. Support for this in real world X.400 implementations is far
from
> > uniform. At least part of the reason why this is so is because this 
> capability
> > is rarely used, and rarely used capabilities are bound to have bugs, 
> especially
> > given that most X.400 implementations are rarely updated these days.
>
>I don't know what X.400 systems you are basing the above comment on. I've 
>been involved with interoperability testing STANAG 4406 PCT (just CMS 
>really), and we have not seen a single problem with an X.400 MTA being 
>unable to relay the new content type.

============================================================================
================
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: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 19 Dec 2001 11:59:28 -0500

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)
- 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.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: [email-masked]
Date: Fri, 21 Dec 2001 18:39:06 -0800 (PST)

> (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.

> to all" action should include amy but not include bill.

The rules for header merging from message/partial can probably be applied
here.

				Ned