所以你的问题是如果附件的内容类型设置为 content-type =message / rfc822，则至少有一些电子邮件客户端会错误地保存MHTML附件。

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".

首先，值得注意的是，您对该问题的根本原因的分析是有缺陷的。您似乎感到困惑，因为 multipart / related MIME类型发挥作用。事实上， RFC 2557 并不表示对应于MHTML附件的正文部分必须有 content-type =multipart / related。相反，MIME multipart / related是MHTML文件本身的内部结构。引用***文章：

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:

MHTML文件的内容被编码为使用MIME类型multipart /相关的HTML电子邮件消息。

The content of an MHTML file is encoded as if it were an HTML e-mail message, using the MIME type multipart/related.

也就是如果您使用文本编辑器打开MHTML文件，您应该看到以下内容：

I.e. if you open MHTML file with text editor, you should see the following:

Content-Type: multipart/related; ...

Microsoft声明MHTML文件应以内容类型= KB937912 中的message / rfc822。当您通过 AddAttachment 方法附加此类文件时，这正是CDO默认执行的。我认为这样的行为与RFC 2557无关。根据RFC：

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:

有许多文档格式...指定
文档，包括根资源和一些由该根资源中的URI引用的不同
辅助资源。
显然需要能够在电子邮件[SMTP]，[RFC822]消息中发送这样的多资源
文件。

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.

本文档中定义的标准规定了如何聚合MIME格式的[MIME1至MIME5]消息
中的
多资源文档，正是为此目的。

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.

要概述，绝对不应该将MHTML附件的内容类型设置为 multipart / related 。

To recap, you definitely should not set content type of MHTML attachment to multipart/related.

虽然 message / rfc822 似乎是与MHTML文件一起使用的方式，但它显然会触发您所描述的问题在这个问题。我使用Outlook 2010和OWA 2010进行了测试，并能够复制它。

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.

各种电子邮件客户端用于MHTML附件的替代内容类型为 application / octet-stream 和 application / x-mimearchive 。这两个在我的测试中没有出现问题。

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.