[Top] [All Lists]

Re: 2 MIME questions re: message/rfc822

2004-11-06 17:16:53

Some quick comments:

I'm not convinced 2a is a showstopper, but then I'm happy with just signing whatever isn't whitespace on any headers we don't make special rules for.

Does anybody
care, and more to the point, will anybody actually implement it?

I suspect this is worth doing, if only to address the problems that I anticipate will follow upon the apparent inevitability of some form of domain signatures. I am particularly worried about messages that are signed at different times by multiple mechanisms for multiple purposes. It's going to be complicated, and it would be nice if implementors all did it at least *roughly* the same way. :-(

There may be a way around that; simply define a discrete media
type that otherwise looks like message/rfc822 -- maybe
application/rfc822 a la message/http vs. application/http. That
discrete media type could then have protective encoding applied
for transport without violating the rule regarding identity
encodings of composite media types.  Of course that won't be
"transparent" in the same sense as message/rfc822

And the only difference would be that if you were signing it, you gave it the primary type "application" instead of "message"? That makes me unhappy because now we're saying that the data type depends on the way the data is being protected/wrapped/used. (It's like saying I'm a girl if you put in me in a gown, but a boy if you put me in a tux.) Let's say that I forward you a message that is encapsulated as a message/rfc822 object. Imagine further that at the outgoing gateway from my email domain, a PGP signature is being applied. Would you have the software that is doing the signing also change the content-type of the embedded object? Would you have decoding software change it back? If so, what you're really doing is building into the PGP signature algorithm a small "transfer-encoding" that specifically protects headers in a message/rfc822 object and nothing else. I'm not saying that wouldn't work, but there's got to be a prettier way to do things..... doesn't there? -- Nathaniel