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

emailmimerfc

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?

Best Answer

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

Related Solutions

Are two periods allowed in the local-part of an email address

Yes you are correct. The section you quoted says that it must be a quoted string OR a dot atom. Since its clearly not a quoted string (the lack of enclosing " makes that clear) it must be a dot-atom...

That leads us to the definition of dot-atom:

Look at this except from RFC 5322 (3.2.3 - page 13) (RFC 2822 contains a similar section) the hint is the 1* in dot-atom-text = 1*atext *("." 1*atext). This effectively means that a dot-atom is made up of strings of one or more "atext" characters separated by dots. A string of 0 atext characters does not count and so you can not have two successive dots (seperated by 0 characters) or a leading or trailing dot.

RFC 5322                Internet Message Format             October 2008


   atext           =   ALPHA / DIGIT /    ; Printable US-ASCII
                       "!" / "#" /        ;  characters not including
                       "$" / "%" /        ;  specials.  Used for atoms.
                       "&" / "'" /
                       "*" / "+" /
                       "-" / "/" /
                       "=" / "?" /
                       "^" / "_" /
                       "`" / "{" /
                       "|" / "}" /
                       "~"

   atom            =   [CFWS] 1*atext [CFWS]

   dot-atom-text   =   1*atext *("." 1*atext)

   dot-atom        =   [CFWS] dot-atom-text [CFWS]

   specials        =   "(" / ")" /        ; Special characters that do
                       "<" / ">" /        ;  not appear in atext
                       "[" / "]" /
                       ":" / ";" /
                       "@" / "\" /
                       "," / "." /
                       DQUOTE

What does this Received email header line mean

It is common to see localhost (127.0.0.1) in the received headers. This indicates that a program running locally is re-injecting the message into the mail stream. Spam filters are often run this way, although it is better to filter spam at the Internet boundary and reject the message before it has been accepted.

I often see headers with no incoming address, or a pair of received headers for the same host. Although there is a standard to be followed, it has some flexibility, and several email processing programs seem to invent or guess at the format.

I think of a few reasons your name is replaced by 127.0.0.1 in the header.

Connection is from a proxy or relay running on the same host which doesn't add its own received header.
Your DNS entries don't pass reverse DNS validation.
The value 127.0.0.1 is a reply from a black or white list server.
The value has been coded into their header template.

EDIT:

I have looked at too many Received headers, and found that some appear to be useful only to someone with access to the server that generated it. Different servers use different rules for building the header, and some allow the administrator to provide their own custom template. I generally don't trust the server to correctly to log it's own name, but find the upstream server is usually correct. Spam may have additional headers which attempt to obscure the real routing.

Related Topic

Linux – Convert a raw email message to plain text in linux