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?