On Sat, 2 Oct 2004, John Levine wrote:
I agree that it is desirable that a signature be resistant to mangling
as a message is forwarded and reformatted. On the other hand, I also
think it is desirable that a signature cover the headers that are
likely to be displayed to the user. Unless we think we're vastly
smarter than the people who designed S/MIME, their experience tells us
that we can't have both. They worked hard and came up with a scheme
that signs message bodies in a robust way but in view of the amazing
variety of ways that MTAs and MUAs mangle headers (Exchange and
Outlook are the poster children here), they left headers entirely out
of the story.
Actually, this is not quite right. The issue is more subtle than this.
In the early days of the development of all secure email technologies,
there was very little support from MUAs. Even as MIME was "being
deployed", one of the features whose support was problematic at best in
MUAs was displaying embedded "message/rfc822" parts.
In point of fact, all secure email technologies will correctly and
perfectly protect email headers and bodies. All that is required is to
apply the technology to a "message/rfc822". And to make that work in a
robust way requires little more than a profile of the headers to include
in the embedded body part.
Now, the real issues come on the receiving side. How do you display all
this so it makes sense to the user? What do you do when the inner
headers do not agree with the outer headers?
As if understanding secure email wasn't hard enough, consensus on the
answers to those questions was unachievable.
I have not recently considered the current support of message/rfc822. I
would hope the situation has improved such that a more reasonable
discussion of protecting headers with a "message/rfc822" embedded body
part could occur.
And I would consider this group "smarter" than the people who designed
all the secure email techologies on this point. After all, we're email
people and we have much more experience now than we had then
implementing email and meeting the needs of the email user community.
Jim