Gmail是否为内联附件设置了无效的Content-ID标头?

Ale*_*rin 5 gmail mime rfc822 mime-message

精简版

附件上的Content-ID标头必须是表单local-part "@" domain.Gmail的Content-ID中没有内容@.这是一个真正的错误,还是我误读了规范?

长版

当我尝试重新发送从Gmail发送的附有内联图片的电子邮件时,我发现了这个问题.我的邮件程序(SwiftMailer)声称Content-ID无效.

这是我正在使用的电子邮件.我是通过在Gmail中插入内嵌图像并通过电子邮件发送给自己来创建的.

以下是规范的相关部分(据我所知):

RFC 2045

Content-ID Header Field

In constructing a high-level user agent, it may be desirable to allow
one body to make reference to another.  Accordingly, bodies may be
labelled using the "Content-ID" header field, which is syntactically
identical to the "Message-ID" header field:

 id := "Content-ID" ":" msg-id
Run Code Online (Sandbox Code Playgroud)

RFC 822 在这里这里

msg-id      =  "<" addr-spec ">"            ; Unique message id

addr-spec   =  local-part "@" domain        ; global address
Run Code Online (Sandbox Code Playgroud)

我在这里错过了什么?Gmail是否遵循规范,或者没有@内容ID?

Pee*_*eja 8

看来没有人发布更好的答案......

我对RFC的解释与您的一致.我认为Gmail在这里做错了.但是,根据定义,Gmail所做的事实上是有效的.Gmail太受欢迎,因为其他软件无法接受,但它会做一些事情,这为更多软件以相同方式违反规范打开了大门,直到它成为标准做法.

不幸的是,这意味着目前没有与现实相符的确切规范.幸运的是,这个问题现在出现在谷歌的结果中.


问题中的原始电子邮件已经消失,所以这是另一个例子.这只是多部分消息的编码图像部分.请注意Content-ID标头.

--089e0153807e5a346d04f1ae7c38
Content-Type: image/gif; name="blank.gif"
Content-Transfer-Encoding: base64
Content-ID: <ii_14403b4fa16783bf>
X-Attachment-Id: ii_14403b4fa16783bf

R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==
--089e0153807e5a346d04f1ae7c38--
Run Code Online (Sandbox Code Playgroud)