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