Fails to parse Gmail's (incorrect) Content-ID headers #663

Peeja opened this Issue Feb 5, 2014 · 4 comments


None yet
2 participants

Peeja commented Feb 5, 2014

I'm not sure what the right solution to this is.

When Gmail creates an email with an inline image, it gives it a Content-ID which looks like:

Content-ID: <ii_14403b4fa16783bf>

Now, that's not actually a valid Content-ID, because it's missing an @. Accordingly, Mail refuses to parse it as one. If I parse an email like this with Mail, its inline_image_part.header[:content_id].field is a UnstructuredField, not a ContentIdField.

There's a StackOverflow question with more details.

Should Mail parse a Content-ID like this? In general I'd say follow the spec, but these days Gmail is the spec.

If it shouldn't, what should people do if they need to parse Gmail Content-IDs?


carsonreinke commented Feb 8, 2014

Seeing the same thing. I wonder how other libraries handle this inconsistency.


Peeja commented Feb 8, 2014

I found a (partial?) solution:


That will give you what's inside the brackets whether it's a legal Content-ID or not. That covered my use case. Does it cover yours, @carsonreinke? If so, I think we can close this.


carsonreinke commented Feb 21, 2014

@Peeja, yes, that works. Thanks!


Peeja commented Feb 21, 2014

Awesome. That seems like it covers the issue, then, so I'll close it.

Peeja closed this Feb 21, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment