[Top] [All Lists]

RE: Protection of header elements in an S/MIME message

2005-02-01 23:02:02


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.


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

"Protecting fields via message/rfc822 and merging issues"

"The subject line leakage problem"

Blake Ramsdell | Sendmail, Inc. |