我们拥有的两种不同的第三方电子邮件产品对电子邮件的 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”方案是指消息的特定正文部分；它的使用通常仅限于引用与引用正文部分相同的消息中的其他正文部分。“mid”方案还可以通过包含内容ID的地址来指代指定消息内的特定正文部分。
所以，虽然不是绝对的，我们倾向于认为，既然所有的嵌入式项目需要的CID引用他们，并且它是“一般仅限于相同的消息在身体其他部位，”和附件并不需要一个CID ，电子邮件产品将 cid 的存在视为“意图嵌入”的指标是合理的行为。
我可以得到确认吗？
在Content-ID并不表示一个图象显示的内联。需要此标头来引用 HTML 中的嵌入数据。
由于电子邮件是文本消息，因此没有理由显示嵌入的图像，只要邮件是纯文本即可。
无论格式是 HTML 还是纯文本，一些客户端都会内联显示数据。但这不是一个明确的行为
我认为您正在寻找Content-Dispositionheader 字段，它允许您将正文部分（例如图像）的呈现样式定义为inlineor 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"
您可以在以下位置阅读更多信息：