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

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?

Solution 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

Solution 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:

• The RFC: https://www.rfc-editor.org/rfc/rfc2183
• Wikipedia: http://en.wikipedia.org/wiki/MIME#Content-Disposition

Solution 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.