The technical feature of this specification is to allow non-security-aware
MIME implementations to handle objects which are signed but not sealed.
That is, cleartext is still accessible.
Thank you for this clear description. I must, however, press this issue.
One of the technical arguments that was presented against the multipart
security specification is that, in fact, non-security-aware MIME
implementations would not correctly handle a multipart message construct
that they had not seen before, effectively rendering the cleartext
inaccessible.
First of all, this simply isn't true. Even in the case when a non-MIME agent is
used the cleartext can not only be readable and accessible, MIME also tries to
minimize the clutter that appears before it. The result is that a cleartext
message which could be read prior to MIME processing before security
enhancement can still be read after enhancement. This isn't perfect by any
means, but it does work fairly well in most cases.
Second, as for support for unrecognized subtypes of multipart, the MIME
specification is EXTREMELY clear on this point. The conformance section says
that any unrecognized subtype of multipart must be treated as multipart/mixed.
There is no option here -- implementations must do this in order to claim MIME
support.
So, I think it's fair to ask the larger audience:
Is there a proscribed behaviour for handling a new multipart construct ?
Sure there is. And its been in place since RFC1341, which said the same thing
as the current draft does. There was never any excuse for getting this wrong.
What do current MIME implementations do in this situation ?
I can only speak to the ones I know about, of course. Pine is possibly the most
commonly used MIME user interface around right now, and it handles unknown
subtypes of multipart as equivalent to multipart/mixed. This is just as it
should be.
The MH extensions to handle MIME that I have seen also handle unknown subtypes
of multipart properly. (More specifically, MHN generally provides a means by
which a general rule for a type that applies to all subtypes can be specified.)
The MIME agent I use, PMDF MAIL, handles this correctly as well.
Its been a while since I've used them, but I believe Z-Mail, Ishmail, and
UltiMail all handle unknown subtypes of multipart properly.
MetaMail is used as a core building block by lots of other MIME agents. (I
believe Elm's support for multipart is based on MetaMail, for example.) Its
built in multipart support handles unknown subtypes as multipart/mixed. Given
this support, I suspect that by and large most agents will get this right.
In summary, all of the MIME agents I'm familiar with handle unknown subtype of
multipart properly. I've heard rumors to the effect that old versions of
Netscape fail to handle multipart properly (up to and including not being able
to handle multipart/mixed!), but I have not encountered this problem myself.
I note in passing that if you believe that if unknown subtypes of multipart
aren't handle properly there is no reason to believe that multipart/alternative
will be handled properly either. I have yet to encounter any agents that have
any problem with unknown subtypes, but I do know of several agents (including
the one I happen to use) that don't handle multipart/alternative very well. As
such, the S/MIME "solution" of using multipart/alternative in lieu of security
multiparts is in my opinion nothing of the sort -- it simply replaces one
mechanism that might not be implemented with another that's even less likely to
be implemented. It makes the problem worse, not better.
Ned