Home / server / Questions / 398962
In Process
Mike B
Asked: 2012-06-15 13:53:51 +0800 CST

Does the presence of a Content-ID header in an email MIME mean that the attachment must be embedded?

  • 772

Two different third-party email products we have are reacting differently to the presence of a content-id header in the MIME source of an email. This is resulting in an inconsistent user experience that we're trying to resolve.

Here's an example: 

--boundary-example
Content-Location: CID:somethingatelse 
Content-ID: <foo4atfoo1atbar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNv
cHlyaWdodCAoQykgMTk5LiBVbmF1dGhvcml6ZWQgZHV
wbGljYXRpb24gcHJvaGliaXRlZC4A etc..

One email product interprets this as an embedded image. The other interprets this as an ordinary attachment (not embedded). If we completely remove the Content-ID line, both products think the attachment is not embedded.

Is there a specific RFC that definitively concludes which behavior is correct? A colleague and I reviewed RFC2392 which in the opening abstract says:

The use of [MIME] within email to convey Web pages and their
associated images requires a URL scheme to permit the HTML to refer
to the images or other data included in the message. The Content-ID
Uniform Resource Locator, "cid:", serves that purpose. […] The "cid" scheme refers to a specific body part of a message; its use is generally limited to references to other body parts in the same message as the referring body part. The "mid" scheme may also refer to a specific body part within a designated message, by including the content-ID's address.

So, while not absolute, we're inclined to believe that since all embedded items need a cid to reference them, and that it is “generally limited to other body parts in the same message,” and that attachments don’t need a cid, it is reasonable behavior for an email product to treat the presence of a cid, as an indicator of “intent to embed”.

Can I get confirmation on this?

email rfc mime

3 Answers

  1. The Content-ID does not indicate that a image should be displayed inline. This header is needed to reference the embedded data within HTML.

    As an email is a text-message there is no reason to display an image embedded, as long as the mail is plain-text.

    Some clients does display the data inline regardless of the format is HTML or plain-text. But this is not a defined behaveior

    • 9

  2. I think you're looking for the Content-Disposition header field, which allows you define the presentation style of a body part (such as an image) to be inline or attachment.

    Here's an inline example created by Thunderbird:

    --------------040202010204080305090405
Content-Type: image/png; name="test.png"
Content-Transfer-Encoding: base64
Content-ID: <[email protected]>
Content-Disposition: inline; filename="test.png"

    You can read more at:

    • 9

  3. Here what would be my approach to this.

    If you are a sender

    Always add a Content-Disposition header to your attachment. Either by indicating inline or attachment, with the filename. Such as:

    Content-Disposition: attachment; filename="test.png" or Content-Disposition: inline; filename="test.png"

    This will remove any ambiguity.

    If you are a parser/receiver

    1. First, consider all attachments as not inline.
    2. If the attachment has a content-id, consider it inline.
    3. Then, if the attachment has a content-disposition, respect the disposition indicated.

    By doing so that way, you'll ensure that the content-disposition (last check) is always respected, but by default you treat attachments as external except when a CID is provided.

    This works well for most of the emails sent.

    • 1