1

I am just trying to understand how this works. Say I receive an marketing email from a brand or business and that email contains one or more embedded images. What protocol is used for those images downloaded and viewed in the email? Is it ftp, smb, something else? I've tried looking all over the place but I can't find anything that explains that part of the process.

tripleee
  • 175,061
  • 34
  • 275
  • 318
Polorboy
  • 11
  • 3

1 Answers1

2

Your question isn't entirely well-defined. This answer thus attempts to provide some context, and cover multiple bases within that context.

In very brief summary, the simplest and most robust solution is to embed the images as MIME parts within the message itself; an HTML body part can use the cid: protocol to refer to them by their MIME Content-Id:

For a more detailed exposition, let's start with a historical recap. Back in the days of the original RFC822 from 1982 (and its even older pre-SMTP precursors) the format of email was basically restricted to 7-bit US-ASCII plain text (no bold or italics; no fonts or images, and certainly no audio or animations).

Informally, where both parties were in agreement, a different 7-bit character set might be used, but of course, a correspondent or third party who wasn't aware of any implicit agreements would be unable to properly decode those messages. For some languages, it would not be hard to guess that s|m@ ch{r{ct@rs h{d b@@n s^bstit^t@d; for others, $%-35; ?-<&? +${ :!``@ '|@&=$$<

The original MIME spec RFC 1341 from 1992 specified a backwards-compatible mechanism for embedding different content types in 7-bit US-ASCII email using a set of content encodings and additional headers. The headers would supply an explicit Content-Type: and Content-Transfer-Encoding: and a way to bundle multiple payloads into a single message using one of several multipart content types.

Let's look at a simple demo message for illustration:

From: me <sender@example.net>
To: you <victim@example.org>
Subject: Hello! =?utf-8?q?=E4=BD=A0=E5=A5=BD=21?=
MIME-Version: 1.0
Content-type: multipart/related; boundary="moooooooo"

--moooooooo
Content-type: text/html; charset="utf-8"
Content-transfer-encoding: quoted-printable

<html><head><title>Demo</title></=
head><body><h1>Demo</h1>
<p>Look!
<!-- The same in Chinese -->
=E7=9C=8B!
<img src="cid:baaaaaaar.png"/>
</p></body></html>

--moooooooo
Content-type: image/png
Content-id: <baaaaaaar.png>
Content-transfer-encoding: base64

notreallyavalidimagejustsomecomputerporridge===

--moooooooo--

Skipping many details here, we can observe that the raw SMTP message is entirely represented as 7-bit US-ASCII, using encodings which allow us to embed representations of 8-bit character sets and even arbitrary binary image data. Each body part has its own set of MIME headers which indicate its content type, transfer encoding, and other relevant metadata.

There are two mechanisms in MIME of interest here for representing an image. The example above embeds an image as a MIME part with the actual image data. Another is the Content-Location: MIME header, which allows you to use any valid URI to link to an on-line resource. (This mechanism sees limited actual use, though.)

There's a second layer, where the specification for a specific MIME type can provide additional facilities. In the case of text/html, the specification for the <img> tag similarly exposes a mechanism for linking to on-line resources using any valid URI, in accordance with the HTML specification. HTML has several other tags with a src attribute which allows you to link to a URI outside the current document, e.g. for scripts, frames, etc.

(However, in actual practice, many email clients implement restrictions around this for security reasons. Nefarious actors in advertising and other immoral or illegal fields are eager to abuse this mechanism to collect information about their targets.)

Other MIME types could offer similar mechanisms to link to external resources by various means. It would not technically be hard to implement a MIME type which requires support for the "avian" (pigeon carrier) protocol, for example.

Much more could be said about various corner cases, but I'm guessing you will be satisfied with the common case of HTML email with <img> tags pointing to a cid: resource, or the familiar HTML URL protocols http:, https:, ftp:, etc. with the caveat that some clients will be configured to not actually fetch those resources without the recipient's explicit approval.

By the way, the relevant specifications have repeatedly been refined and updated. The current SMTP message specification is RFC5322 and the base spec for MIME is now RFCs 2045 through 2049. Some parts of MIME is also now used in other protocols, including HTTP.

Perhaps see also What are the "parts" in a multipart email? which contains some additional exposition and links to more resources.

tripleee
  • 175,061
  • 34
  • 275
  • 318
  • (I'm aware that there is advertising which is neither immoral nor illegal. My engagement in anti-spam activities may have contributed to skewing my impression of which case is the regular and normal one.) – tripleee Apr 01 '23 at 11:17
  • 1
    Epic answer! Thanks for taking the time to share your knowledge. – O. Jones Apr 01 '23 at 11:38