☰

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

tag-icon • tag-icon email mime rfc
电子邮件 MIME 中存在 Content-ID 标头是否意味着必须嵌入附件？

我们拥有的两种不同的第三方电子邮件产品对内容标识电子邮件 MIME 源中的标头。这会导致用户体验不一致，我们正在尝试解决此问题。

以下是一个例子：

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

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

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

是否有特定的 RFC 可以明确得出哪种行为是正确的结论？我和一位同事审阅了 RFC2392，其开篇摘要中写道：

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

因此，虽然不是绝对的，但我们倾向于相信，由于所有嵌入的项目都需要一个 cid 来引用它们，并且它“通常仅限于同一封邮件中的其他正文部分”，并且附件不需要 cid，电子邮件产品将 cid 的存在视为“嵌入意图”的指标是合理的行为。

我可以确认这一点吗？

答案1

并不Content-ID表示图像应以内联方式显示。需要此标头来引用 HTML 中的嵌入数据。

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

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

答案2

我认为您正在寻找Content-Disposition标题字段，它允许您定义正文部分（例如图像）的呈现样式为inline或attachment。

以下是 Thunderbird 创建的内联示例：

--------------040202010204080305090405
Content-Type: image/png; name="test.png"
Content-Transfer-Encoding: base64
Content-ID: <[email protected]>
Content-Disposition: inline; filename="test.png"

更多内容可参见：

答案3

这是我对此采取的方法。

如果你是发件人

务必为附件添加Content-Disposition标题。通过文件名指示内联或附件。例如：

Content-Disposition: attachment; filename="test.png"或者Content-Disposition: inline; filename="test.png"

这将消除任何歧义。

如果你是一个解析器/接收者

  1. 首先，将所有附件视为不内联。
  2. 如果附件有 content-id，则将其视为内联。
  3. 然后，如果附件具有内容处置，则尊重所指示的处置。

通过这样做，您可以确保始终尊重内容处置（最后检查），但默认情况下，除非提供了 CID，否则您会将附件视为外部附件。

这对于大多数发送的电子邮件都很有效。

相关内容