当谈到格式时我真的很困惑Content-Id消息部分中的标头。
在我看来，只有RFC 2045 https://www.rfc-editor.org/rfc/rfc2045#section-7涵盖了标头的格式，但很简短：
在构建高级用户代理时，可能需要允许
一个实体引用另一个实体。因此，机构可能是
使用“Content-ID”标头字段进行标记，该字段在语法上是
与“Message-ID”头字段相同：
id := "Content-ID" ":" msg-id
与 Message-ID 值一样，Content-ID 值必须生成为
世界独一无二。
RFC 2822 https://www.rfc-editor.org/rfc/rfc2822#section-3.6.4解释了 a 的格式msg-id像这样的令牌：
消息标识符 (msg-id) 的语法与 angle-addr 类似
无需内部 CFWS 即可构建。
message-id = "消息 ID:" msg-id CRLF
in-reply-to = "In-Reply-To:" 1*msg-id CRLF
参考文献=“参考文献：”1*msg-id CRLF
msg-id = [CFWS] "" [CFWS]
id-left = 点原子文本 / 无折叠引号 / obs-id-left
id-right = 点原子文本 / 无折叠文字 / obs-id-right
无折叠引号 = DQUOTE *(qtext / 引号对) DQUOTE
no-fold-literal = "[" *(dtext / 引用对) "]"
长话短说：它包含 at ('@') 符号，就像Message-Id消息的标题。然而，几乎所有有关 MIME 格式的读者友好文章都给出了以下示例Content-Id withoutat 符号（包括非真正的全局标识符，例如myimagecid or inlineimage001以及随机生成的不带 at 符号的 UUIDS）。如果有必要的话，他们肯定会强调“@”符号的重要性，就像他们对Message-Id标题，对吗？正确的？
我在现实世界的电子邮件客户端上运行了一些测试，看看它们如何使用嵌入的内嵌图像撰写电子邮件：
- Thunderbird 生成带有 at 符号的标识符。例子：
[email protected] /cdn-cgi/l/email-protection
- Gmail 生成标识符without这样的符号并且没有域部分。例子：
ii_abc1234x0_12345ab12abcdefa
我没有测试更多的电子邮件客户端（如果有人这样做，那么完成上面的列表就太好了），但这两个客户端已经显示出显着的差异。 Google 不遵守 RFC 标准？它确实看起来很臭，我想知道这是因为我错过了一些东西，还是因为格式毕竟不是那么重要（从长远来看，这感觉相当令人不安）。我也有兴趣检查有多少流行的电子邮件客户端实际上丢弃了“at”符号。
