All I know is that my MIME application, Frontier Technolgies Super-TCP for
Windows v. 4.0, email version 3.70, doesn't handle multipart messages at all.
It recognizes that there is an attachment, but can't process it. So I can't
read any of the multipart messages that people send from time to time.
(this is not necessarily an endorsement for either approach, just a statement
of current, quasi-brain-dead fact.)
Bob, if this is in fact the case then your problem isn't with your software,
its with what you are calling your software. You call it a "MIME application"
when in fact it is nothing of the sort. Failure to support multipart means you
don't support MIME. Period! Full stop!
However, I'm pretty sure your facts here are incorrect. We did a fair amount of
interoperability testing with Frontier Technolgies Super-TCP at InterOp back in
August of 1993, and it handled multipart correctly, both in terms of displaying
ones created by other agents as well as composing them itself. We threw all
sorts of complex MIME objects around and I believe everything worked quite
well.
We've also done some testing more recently in conjunction with a reported
compatibility problem with our products and failure to properly decode stuff.
In this case it turned out that the user was encoding everything manually
before sending it, leading to multiple encodings the user agents would not (and
should not) undo and once appropriate "behaviorial modifications" were made
things again worked fine. This was with a fairly recent version of the package,
I believe.
My guess is that your problems with multipart are coming from another source --
a local configuration error, dropped header lines, etc. In any case, I
encourage you to contact the vendor and work with them to find a solution
because this is supposed to work properly. Our experiences with Frontier have
been uniformly positive in situations of this sort.
Ned