I also disagree -- it seems that any application that recognizes
multipart/alternative should be quite compatible with signed S/MIME messages
(the first part of the multipart contains text/plain [or whatever] which
everyone recognizes, and the second part contains application/pkcs7-mime
which people may not recognize, and which they will ignore).
I'm quite aware of this approach, and have already discussed it at considerable
length. However, it isn't relevant in this context. I stated that the goal here
was visibility of the cleartext part. Having an alternative is not the same
thing at all since you are not making the thing that's actually signed (i.e.
the cleartext) visible. What is visible is something else entirely. I have
already explained why I don't think using alternative in this way is a viable
approach.
I understand that what you're probably referring to is the single-part
application/pkcs7-mime type that does not use multipart/alternative, but I
figured I'd clarify the point -- especially since we are in the middle of a
discussion about the relative strengths and weaknesses of S/MIME versus MOSS
.
We're not talking about MOSS here. We're talking about security multiparts.
These aren't the same either. A discussion of the relative merits of MOSS
vs. S/MIME's use of PKCS #7 would be interesting but it isn't the topic
at hand.
In contrast to the MOSS standard of multipart/signed, it seems that existing
MIME mail agents are *less* likely to choke on the multipart/alternative
S/MIME messages, since current MIME agents will not recognize the
multipart/signed and may not interpret them according to the specified
fallback rule of multipart/mixed.
My own experience has been exactly the opposite. Support for fallback
interpretation of multipart seems to be quite common. Various people have
posted plenty of examples of agents that do this correctly, and the list
already covers many if not most widely used agents. In fact nobody has posted a
verifiable example of an agent that doesn't do this properly, and I'm the only
one thus far to post an unverified example! The one posting where a genuine
problem with multiparts was observed turned out to be a general problem with
any multipart and the vendor has fixed it already.
Support for alternative, on the other hand, has been quite uneven in my
experience. Often as not interpretation of alternative is based on a fallback
to mixed! In other cases agents have guessed wrong as to the part to display.
Mind you, I don't claim comprehensive knowledge of all the agents out there.
However, I am one of the coauthors of the MIME specification, I make my
living selling MIME-capable software, and I have participated in a very large
number of MIME interoperabiity tests over the past few years.
I think this is the point that Steve was
making originally. This behavior seems to be supported by other
contributions to the list in response to Steve's original question about
handling unknown multipart constructs.
Really? Every posting I've seen in this recent discussion has cited agents
that do multipart, and thus are a direct contradiction of what Steve said.
And I have also pointed that even agents that don't support MIME in any way
will usually present the cleartext component of a security multipart in a
reasonably legibile fashion. And despite your assertions to the contrary, this
is *not* something S/MIME is capable of. The best it can do is present an
unnecessary duplicate of the signed cleartext, which costs you over 100% in
overhead and opens the door to various potentially serious security problems.
Ned