Does Gmail set an invalid Content-ID header for inline attachments?

Question

Short Version

A Content-ID header on an attachment must be of the form local-part "@" domain. Gmail's Content-IDs do not have an @ in them. Is this a real bug, or am I misreading the spec?

Long Version

I noticed this problem when I tried to resend an email sent from Gmail that has an inline image attached. My mailer (SwiftMailer) claimed that the Content-ID was invalid.

Here's the email I'm working with. I created this by inserting an image inline in Gmail and emailing it to myself.

Here are the relevant parts of the spec (as far as I can tell):

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

RFC 822 here and here

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

addr-spec   =  local-part "@" domain        ; global address

What am I missing here? Is Gmail not following the spec, or is it ok not to have an @ in the Content-ID?

Oleum

Came here to ask the exact same question. In my case, the Rubygem mail is having trouble parsing these Content-IDs correctly. – Elora

I wonder if there's a way to get in touch with someone on the Gmail team about this. It may not be that hard to add a @gmail to the end of their content id generator. – Oleum

Answer 1

Seeing as no one's posted a better answer…

My interpretation of the RFCs fits with yours. I'd say Gmail's doing the wrong thing here, by the book. However, what Gmail does is de facto valid by definition. Gmail is too popular for other software not to accept however it does things, which opens the door for more software to violate the spec in the same way until it's standard practice.

Unfortunately that means there's currently no exact spec that matches reality. Luckily this question comes up in Google results now.

---

The original email in the question is gone, so here's another example. This is just the encoded image portion of the multipart message. Note the Content-ID header.

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

R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==
--089e0153807e5a346d04f1ae7c38--

Elora

Recently, I've seen GMail do this: Content-Type: image/png; name="image002.png" Content-Disposition: inline; filename="image002.png" Content-Transfer-Encoding: base64 Content-ID: <> – Plumbum