Content-Id 标头的精确格式

Question

当涉及到Content-Id消息部分中标题的格式时，我真的很困惑。

在我看来，只有RFC 2045涵盖了标头的格式，但很简短：

在构建高级用户代理时，可能希望允许一个主体引用另一个主体。因此，可以
使用“Content-ID”头字段标记正文，该字段在语法上
与“Message-ID”头字段相同：

 id := "Content-ID" ":" msg-id

与 Message-ID 值一样，Content-ID 值必须生成为世界唯一的。

RFC 2822解释了msg-id令牌的格式，如下所示：

消息标识符 (msg-id) 在语法上类似于没有内部 CFWS 的angle-addr 构造。

message-id = "Message-ID:" msg-id CRLF

in-reply-to = "In-Reply-To:" 1*msg-id CRLF

参考 = "参考:" 1*msg-id CRLF

msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]

id-left = dot-atom-text / no-fold-quote / obs-id-left

id-right = dot-atom-text / no-fold-literal / obs-id-right

no-fold-quote = DQUOTE *(qtext /quoted-pair) DQUOTE

no-fold-literal = "[" *(dtext /quoted-pair) "]"

长话短说：它包含 at ('@') 符号，就像Message-Id消息的标题一样。然而，几乎所有关于 MIME 格式的对读者友好的文章都给出了Content-Id 不带at 符号的示例（包括非真正的全局标识符，如myimagecid或inlineimage001以及随机生成的不带 at 符号的 UUIDS）。如果有必要，他们肯定会强调“@”符号的重要性，就像他们对Message-Id标题所做的那样，对吗？对？

我在现实世界的电子邮件客户端上运行了一些测试，看看它们是如何用嵌入的内嵌图像撰写电子邮件的：

• Thunderbird 使用 at 符号生成标识符。例子：part1.12345678.12345678@domain.example.com
• Gmail 生成的标识符没有这样的符号，也没有域部分。例子：ii_abc1234x0_12345ab12abcdefa

我没有再测试任何电子邮件客户端（如果有人测试过，完成上面的列表会很棒），但这两个客户端已经显示出惊人的差异。谷歌不遵守 RFC 标准？它看起来确实很臭，我想知道这是因为我错过了什么，还是因为格式毕竟不是那么重要（从长远来看，这感觉相当令人不安）。我也有兴趣检查有多少流行的电子邮件客户端实际上丢弃了“at”符号。

Answer 1

遵循规范所说的，而不是某些邮件客户端所做的。

所以是的，Content-Id标题应该有一个符合规范所说的方式的值，因此应该有一个“@”符号。

电子邮件世界是一个破碎的地狱，许多不同的邮件客户端和服务器在做自己的事情而不遵守标准。

作为过去 17 年编写邮件软件的人，我可以向您保证，这不是 Google 偏离规范的唯一地方。