Is there a proscribed behaviour for handling a new multipart construct ?
Yes. It's supposed to be handled the same as multipart/mixed.
Hence an non-security aware implementation should still have useful access
to the cleartext portion. Folks should note that this same access is NOT
possible with non-s/mime aware implementations.
I disagree. (Maybe I'm missing something.) Please explain.
I'm not sure what there is to disagree with here. S/MIME uses an ASN.1 encoding
with the cleartext embedded inside. This in turn will most likely be encoded
using base64, making it completely opaque to a non-MIME-capable agent. Even if
it is encoded with quoted-printable it is almost certainly going to be
completely illegible. If you don't believe me try encoding some ASN.1 with
quoted-printable and see -- I've done it and the results are, in my opinion,
beyond what average users are willing to put up with.
When security multiparts are used, however, the cleartext isn't embedded in
ASN.1 and generally speaking doesn't have to be encoded. An unencode message
may get damaged, however, so its best to at a minimum encode using
quoted-printable. The resulting cleartext will be relatively safe from damage
but can still be read without a MIME agent. As I already said, the results
aren't perfect but in my opinion it is something the average user can put up
with.
You can work around this, sort of, by doing what the S/MIME specification
recommends -- duplicate the entire content and use multipart/alternative.
However, this is NOT the same as providing direct access to the cleartext --
all this does is make an additional copy of the cleartext and present that.
The distinction is quite important because it gives rise to the two problems
I have already described: (1) 100% overhead and (2) Serious potential
vulnerability because of the split between what is signed and what is
actually read.
Ned