On Fri November 5 2004 08:32, Nathaniel Borenstein wrote:
Let me be
the first to say that at least part of the problem here may be in the
MIME standard itself.
This situation could in theory be avoided by simply applying a suitable
content-transfer-encoding to the embedded message/rfc822 object
*before* PGP-signing it, thus protecting against line wrapping.
However, this is explicitly *prohibited* by the MIME standard, as per
RFC 2046:
> No encoding other than "7bit", "8bit", or "binary" is
permitted for
> the body of a "message/rfc822" entity.
That may still have been the right design decision -- forbidding
protective C-T-E's for multipart and message makes message structure
much more transparent -- but as far as I can tell, there is NO
legitimate way to encode and sign a message/rfc822 object to protect
against line wrapping in the header fields of the embedded
message/rfc822 object.
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.
This has been proposed numerous times, but none of the proposals have
made it to RFC status.
Ned