You can clone with
HTTPS or Subversion.
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:
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?
Seeing the same thing. I wonder how other libraries handle this inconsistency.
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.
@Peeja, yes, that works. Thanks!
Awesome. That seems like it covers the issue, then, so I'll close it.