我们所使用的两种不同的第三方电子邮件产品对电子邮件的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.. 一个电子邮件产品将其解释为embedded式图像。 另一个解释这是一个普通的附件（不embedded）。 如果我们完全删除Content-ID行，两个产品都认为附件没有embedded。
有没有一个特定的RFC明确地断定哪个行为是正确的？ 一位同事和我回顾了RFC2392，在开篇摘要中说：
在电子邮件中使用[MIME]传达网页及其内容
关联的图像需要一个URLscheme来允许HTML引用
到消息中包含的图像或其他数据。 Content-ID
统一资源定位符“cid：”用于此目的。 […]“cid”scheme是指消息的特定身体部分; 其使用通常仅限于在引用身体部位的相同消息中引用其他身体部位。 “中”scheme也可以通过包括内容ID的地址来引用指定消息内的特定身体部位。
所以，虽然不是绝对的，但是我们倾向于相信，因为所有embedded的项目都需要一个cid来引用它们，并且它“通常仅限于同一消息中的其他身体部分”，并且附件不需要cid作为“embedded意图”的指示符，电子邮件产品将cid的存在视为合理的行为。
我可以得到这个确认吗？
我想你正在寻找Content-Disposition标题字段，它允许你定义一个正文部分（如图像）的performanceforms是inline还是attachment 。
以下是由Thunderbird创build的内联示例：
--------------040202010204080305090405 Content-Type: image/png; name="test.png" Content-Transfer-Encoding: base64 Content-ID: <[email protected]> Content-Disposition: inline; filename="test.png"
你可以阅读更多：
Content-ID并不表示应该以内联方式显示图像。 这个头文件需要引用HTML中的embedded数据。
由于电子邮件是文本消息，因此只要邮件是纯文本，就没有理由显示embedded的图像。
有些客户端显示内联数据，不pipe格式是HTML还是纯文本。 但是这不是一个明确的行为