Why do you think this is a problem? Is it because you think that the
messages will end up mangled in transit or because there has to be a user
interface component?
If the latter I agree but I think the answer is to layer on a CA
authenticated 'letterhead' for signed messages from accredited sources using
the X.509 logotype extension.
Phill
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Jim
Schaad
Sent: Wednesday, February 02, 2005 1:12 AM
To: 'Blake Ramsdell'
Cc: ietf-smime(_at_)imc(_dot_)org; rohan(_at_)ekabal(_dot_)com
Subject: RE: Protection of header elements in an S/MIME message
Blake,
It's actually my opinion that MASS is a non-starter because
they are trying too hard to makes sure nobody sees that it
exists. I think they should take the hit of saying -- see I
have MASS implemented. I guess I get to try and be loud at the IETF.
jim
-----Original Message-----
From: Blake Ramsdell [mailto:blake(_at_)sendmail(_dot_)com]
Sent: Tuesday, February 01, 2005 12:37 PM
To: ietf(_at_)augustcellars(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org; rohan(_at_)ekabal(_dot_)com
Subject: Re: Protection of header elements in an S/MIME message
Jim Schaad wrote:
Actually given the text that you have in the message draft,
I consider
it to be useless and I don't know of anybody who is going
to be able
to deal well with the message. Its not very backwards compatable
(i.e. no current implementation will handle it well) and
its not well
defined for how header comparision is done.
Ouch. But yes, you're absolutely correct that nobody will be
able to deal well with the message (with the definition of
"well" being defined as "merging the headers in an
unambiguous way that represents both the intent of the sender
and the desire of the receiver").
Since MASS is not using S/MIME in any way shape or form, I
doubt you
are offending them.
I am offending them in that the way I would solve this
problem is by putting headers in an inner attachment, which
you've pointed out (twice) is a non-starter for them. If we
try to come up with a unified mechanism for doing this, my
strawman would be:
1. Inner message/rfc822
2. Rules for merging headers
3. What to do about required external headers and how to
placate people who require them ("placebo" headers)
If anyone's interested, there are at least two relevant
threads in the
archive:
"Protecting fields via message/rfc822 and merging issues"
"The subject line leakage problem"
Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com