【发布时间】：2017-01-27 09:24:36
【问题描述】：
当谈到消息部分中Content-Id 标头的格式时，我真的很困惑。
在我看来，只有RFC 2045 涵盖了标题的格式，但是很简短：
在构建高级用户代理时，可能需要允许 一个机构来参考另一个机构。因此，身体可能是
使用语法上的“Content-ID”标头字段进行标记
与“Message-ID”标头字段相同：id := "Content-ID" ":" msg-id与 Message-ID 值一样，必须生成 Content-ID 值才能 世界独一无二。
RFC 2822 解释了msg-id 令牌的格式，如下所示：
消息标识符 (msg-id) 在语法上类似于角度地址 在没有内部 CFWS 的情况下构建。
message-id = "Message-ID:" msg-id CRLF
in-reply-to = "In-Reply-To:" 1*msg-id CRLF
references = "参考：" 1*msg-id CRLF
msg-id = [CFWS] "" [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 以及随机生成的 UUIDS没有 at 符号）。如果有必要，他们肯定会强调“@”符号的重要性，就像他们对Message-Id 标头所做的那样，对吧？对吧？
我在真实世界的电子邮件客户端上运行了一些测试，看看他们如何使用嵌入的内嵌图像撰写电子邮件：
- Thunderbird 生成带有 at 符号的标识符。示例：
part1.12345678.12345678@domain.example.com - Gmail 生成标识符没有这样的符号，也没有域部分。示例：
ii_abc1234x0_12345ab12abcdefa
我没有再测试任何电子邮件客户端（如果有人测试过，最好完成上面的列表），但这两个已经显示出显着的差异。谷歌不遵守 RFC 标准？它看起来确实很臭，我想知道那是因为我错过了什么，还是因为格式毕竟不是那么重要（从长远来看，这感觉相当令人不安）。我也有兴趣检查有多少流行的电子邮件客户端实际上丢弃了“at”符号。
【问题讨论】：
-
已被 RFC 5322 废弃。