On Fri November 5 2004 08:32, Nathaniel Borenstein wrote:
While I repeat that there is a surfeit of candidates at which to point
a finger in this case, we may not yet have gone deep enough. 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:
[...]
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. In other words, if you want to forward a full
message including long Received headers, and you want to sign the
forwarding message with PGP, you may be simply out of luck.
No, RFC 1847 is quite clear that multipart/signed (as used with
PGP per RFC 3156) should not be modified. We can't tell for
certain whether the message described by Valdis was encapsulated
in multipart/signed (though I would guess that it might have been,
considering that his message describing the situation was a
multipart/signed message).
One problem is that really "ancient" MIME implementations
(predating RFC 1847) will treat multipart/signed as multipart/mixed,
and might modify content. Non-MIME-aware implementations
of MSAs, MTAs, list expanders, MDAs, etc. likewise might not
handle multipart/signed in accordance with RFC 1847, and
then of course there is the distinct possibility of non-conforming
recent implementations which are intended to be MIME-aware
but which botch multipart/signed. Returning to multipart/mixed,
the MIME specification doesn't explicitly state that either
multipart/mixed or unrecognized multipart subtypes treated as
mixed shouldn't be modified. Is that a problem with the MIME
standard(s)? Maybe.
I fully agree with your initial observation; there are so many
things that might have gone wrong, piled on top of at least
one thing that we can be sure that the sender did wrong,
coupled with insufficient information (we don't know whether
the "message" was in canonical line-ending form before
signing, we don't know where the "From " line was elided
or where the Received field was unfolded, etc.), that we
can't definitively identify all of the problems.