Let's say you have a multipart/mixed where the third part is 8bit and labelled
as follows:
I see. The thorny issues seem to arise when a multipart is PEM enhanced.
Same thing applies to message/rfc822, actually.
Is it not possible to limit CTE changes to the application/pem-clear
There's no such thing as application/pem-clear. I would not object strongly to
changing the name of message/pem-clear to this, but I do think message is a
bit more appropriate.
or application/pem-encrypted body part and not to the body part within?
This is precisely the reason for introducing the extra level of encapsulation!
Without it there's no way to limit the scope short of adding extra semantics to
the multipart/pem, which we cannot do now.
(Presumably, to avoid the issue of doubly encoding something in base64 say,
the body part within should carry a CTE of 8bit....)
The body parts within definitely should be properly labelled, but labelled or
not, double encoding isn't a problem. The MIME-PEM specification quite clearly
calls for the removal of all interior encodings prior to privacy enhancment.
Subsequent to that encodings can only be applied across the entire enhanced
object. This is also a direct result of the extra level of encapsulation.
That is:
Content-Type: application/pem-clear
Content-Transfer-Encoding: quoted-printable (OK to change)
Content-Type: application/X-hairy-8-bit-data
Content-Transfer-Encoding: 8bit (not OK to change)
<the data>
PEM enhancements will be applied to the Content-Type: application/X-hairy...
through the end of the data.
Actually, wouldn't gateways adhere to this as things currently stand since
they don't know that the inner body part is really a MIME body part at all?
Yes! Again, this is precisely why the extra layer was added (and what I went to
great lengths to try to detail in my original response); the only difference
between what you're doing and what MIME-PEM calls for is the name of the
primary type that's used.
Ned