11

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?

Mike B
  • 11,570
  • 42
  • 106
  • 165

3 Answers3

9

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

Thomas Berger
  • 1,700
  • 12
  • 22
9

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: <part1.02080004.04000407@sample.com>
Content-Disposition: inline; filename="test.png"

You can read more at:

Community
  • 1
james.garriss
  • 360
  • 6
  • 17
  • 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. – user2817219 Nov 25 '19 at 10:06
1

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.

Cyril N.
  • 574
  • 1
  • 9
  • 33