Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>So your problem is that at least some email clients save MHTML attachment incorrectly if content type for the attachment is set as <code>content-type="message/rfc822"</code>. </p> <p>First, it is worth noting that your analysis of a root cause of the issue is flawed. You appear to be confused by where <code>multipart/related</code> MIME type comes into play. As a matter of fact, <a href="http://tools.ietf.org/html/rfc2557" rel="nofollow">RFC 2557</a> does NOT state that <em>body part corresponding to MHTML attachment</em> must have <code>content-type="multipart/related"</code>. Instead, MIME multipart/related is internal structure of MHTML file itself. Quoting Wikipedia <a href="http://en.wikipedia.org/wiki/MHTML" rel="nofollow">article</a>:</p> <blockquote> <p>The content of an MHTML file is encoded as if it were an HTML e-mail message, using the MIME type multipart/related.</p> </blockquote> <p>I.e. if you open MHTML file with text editor, you should see the following:</p> <pre><code>Content-Type: multipart/related; ... </code></pre> <p>Microsoft states that MHTML files should be served with <code>content-type="message/rfc822"</code> in <a href="http://support.microsoft.com/kb/937912" rel="nofollow">KB937912</a>. This is exactly what CDO does by default when you attach such file via <code>AddAttachment</code> method. I believe such behavior does not contradict RFC 2557 in any way. As per the RFC:</p> <blockquote> <p>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.</p> <p>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.</p> </blockquote> <p>To recap, you definitely should not set content type of MHTML attachment to <code>multipart/related</code>.</p> <p>While <code>message/rfc822</code> seems to be <em>the</em> 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.</p> <p>Alternative content types that are used by various email clients for MHTML attachments are <code>application/octet-stream</code> and <code>application/x-mimearchive</code>. These two didn't exhibit the problem in my tests.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload