Question

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

在我看来，只有RFC 2045涵盖了标题的格式，无论如何：

在构建高级用户代理时，可能需要允许   一个身体参考另一个。因此，身体可以是
  使用“Content-ID”标题字段标记，该字段在语法上是
  与“Message-ID”标题字段相同：
 id := "Content-ID" ":" msg-id
与Message-ID值一样，必须生成Content-ID值世界唯一的。

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

消息标识符（msg-id）在语法上类似于angle-addr   在没有内部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]“＆lt;” id-left“@”id-right“＆gt;” [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'符号。

Answer 1

按照规范说，而不是通过某些邮件客户端做什么。

所以是的，Content-Id标题应该有一个符合规范所说方式的值，因此应该有一个＆＃39; @＆＃39;符号

电子邮件的世界是许多不同的邮件客户端和服务器在做自己的事情并且不尊重标准的地狱洞。

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

Content-Id标头的精确格式

1 个答案: