电子邮件MIME中Content-ID标头的存在是否意味着必须嵌入附件？

我们拥有两种不同的第三方电子邮件产品，它们对电子邮件的MIME源中存在content-id标头的反应不同。这导致我们试图解决的用户体验不一致。

这是一个例子：

--boundary-example
Content-Location: CID:somethingatelse 
Content-ID: <foo4atfoo1atbar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNv
cHlyaWdodCAoQykgMTk5LiBVbmF1dGhvcml6ZWQgZHV
wbGljYXRpb24gcHJvaGliaXRlZC4A etc..

一种电子邮件产品将其解释为嵌入式图像。另一个将其解释为普通附件（未嵌入）。如果我们完全删除Content-ID行，则两种产品都认为附件未嵌入。

是否有特定的RFC明确地确定哪种行为是正确的？我和一位同事回顾了RFC2392，该文件在开篇摘要中说：

在电子邮件中使用[MIME]来传达网页及其
相关图像需要URL方案，以允许HTML引用
消息中包含的图像或其他数据。Content-ID
统一资源定位符“ cid：”用于该目的。[…]“ cid”方案是指消息的特定正文部分；它的使用通常仅限于在与引用正文部分相同的消息中引用其他正文部分。通过包括内容ID的地址，“中”方案还可以指代指定消息中的特定正文部分。

所以，虽然不是绝对的，我们倾向于认为，既然所有的嵌入式项目需要的CID引用他们，并且它是“一般仅限于相同的消息在身体其他部位，”和附件并不需要一个CID ，电子邮件产品将cid的存在作为“嵌入意图”的指示是合理的行为。

我可以得到确认吗？

在Content-ID并不表示一个图象显示的内联。需要此标头来引用HTML中的嵌入式数据。

由于电子邮件是文本消息，因此只要邮件是纯文本，就没有理由显示嵌入的图像。

某些客户端确实以内联方式显示数据，而不管格式是HTML还是纯文本。但这不是定义的行为

我认为您正在寻找Content-Disposition标题字段，该字段允许您将主体部分（例如图像）的表示样式定义为inline或attachment。

这是Thunderbird创建的内联示例：

--------------040202010204080305090405
Content-Type: image/png; name="test.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.02080004.04000407@sample.com>
Content-Disposition: inline; filename="test.png"

您可以在以下位置阅读更多信息：

• RFC：http：//tools.ietf.org/html/rfc2183
• 维基百科：http：//en.wikipedia.org/wiki/MIME#Content-Disposition