The sender knows you opened it before you finish reading

There is a settled way of talking about email tracking. It is worth asking how much of it survives contact with the detail.

Loading an image is making a request

Messages formatted as web pages can reference images stored on a remote server rather than including them in the file. When your software displays the message, it fetches those images, and the fetch is an ordinary web request.

The server therefore learns that the message was opened, at what moment and from which network address. A tracking image can be a single transparent pixel that is invisible and serves no purpose except being requested. Nothing exotic is involved, and the mechanism is the same one that makes any web page load its illustrations.

The address is unique to you

The image reference contains an identifier generated for a specific recipient and a specific message. That is what turns a general record of requests into a statement that one named person opened one particular email. The same technique reveals whether you opened it repeatedly, which is treated as a signal of interest.

Under load, forwarding a message carries the identifier along, so opens by other people are attributed to the original recipient. This is why an email you forwarded can generate opens at times when you were not reading anything.

What a single request reveals

The request carries the network address you connected from, which usually gives at least an approximate geographic location. It carries an identifier describing the software making the request, revealing the application and often the platform.

The timing tells the sender when you read it, and the pattern across a campaign shows when you are typically active. Location accuracy varies enormously and is often wrong, particularly for mobile connections and corporate networks. Combined across many messages, the pattern is more revealing than the contents of any single open.

Links are wrapped for the same reason

Rather than pointing directly at a destination, a link often points at a redirection service belonging to the sender. The service records that you clicked, along with which link, and then sends your browser onward to the real address. This is why hovering over a link in a marketing message frequently reveals an unfamiliar domain rather than the expected one.

In practice, the redirection also allows the destination to be changed after sending, which has obvious uses in both directions.

Security products wrap links too, so an unfamiliar wrapper is not by itself evidence of anything untoward.

Image proxying changed the picture partially

Some mail providers fetch remote images through their own servers and store cached copies before displaying them to you. The sender then sees a request from the provider rather than from you, which hides your address and your software.

The open itself is still reported, because the fetch happens when the message is displayed rather than when it is delivered. Providers that cache aggressively may fetch once and serve the copy afterwards, which obscures repeated opens. Behaviour differs between providers and changes over time, so no single description applies to every mailbox.

What blocking images actually achieves

Configuring your software not to load remote content prevents the request and therefore prevents the open being recorded. It also breaks the appearance of legitimate messages, which is why most people enable images and forget the trade. Reading in plain text avoids the problem entirely, and it discards formatting that some messages genuinely rely on.

At the protocol level, blocking images does nothing about link wrapping, which records the click regardless of how the message was displayed. Nothing here is a security failure; it is the ordinary behaviour of web content used for a purpose recipients rarely consider.

The takeaway

Nothing was installed and nothing was breached; the message simply asked for a picture.

Understanding the failure mode tells you more than the feature list does.