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:

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

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?

  • ask RFC author or relevant IETF WG, maybe? Sep 14 '12 at 4:38

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


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:

Content-Type: image/png; name="test.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.02080004.04000407@sample.com>
Content-Disposition: inline; filename="test.png"

You can read more at:

  • Content-Disposition header is not always included. Sometimes it is needed to derive whether a part is inline or an attachment based on the headers provided in the question. Nov 25 '19 at 10:06

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.