So your problem is that at least some email clients save MHTML attachment incorrectly if content type for the attachment is set as content-type="message/rfc822"
.
First, it is worth noting that your analysis of a root cause of the issue is flawed. You appear to be confused by where multipart/related
MIME type comes into play. As a matter of fact, RFC 2557 does NOT state that body part corresponding to MHTML attachment must have content-type="multipart/related"
. Instead, MIME multipart/related is internal structure of MHTML file itself. Quoting Wikipedia article:
The content of an MHTML file is encoded as if it were an HTML e-mail message, using the MIME type multipart/related.
I.e. if you open MHTML file with text editor, you should see the following:
Content-Type: multipart/related; ...
Microsoft states that MHTML files should be served with content-type="message/rfc822"
in KB937912. This is exactly what CDO does by default when you attach such file via AddAttachment
method. I believe such behavior does not contradict RFC 2557 in any way. As per the RFC:
There are a number of document formats... that specify documents consisting of a root resource and a number of distinct subsidiary resources referenced by URIs within that root resource. There is an obvious need to be able to send such multi-resource documents in e-mail [SMTP], [RFC822] messages.
The standard defined in this document specifies how to aggregate such multi-resource documents in MIME-formatted [MIME1 to MIME5] messages for precisely this purpose.
To recap, you definitely should not set content type of MHTML attachment to multipart/related
.
While message/rfc822
seems to be the way to use with MHTML files, it obviously triggers the problem you described in the question. I tested with Outlook 2010 and OWA 2010, and was able to reproduce it.
Alternative content types that are used by various email clients for MHTML attachments are application/octet-stream
and application/x-mimearchive
. These two didn't exhibit the problem in my tests.