# Remote images in email

Every remote image in a received message is rewritten to load through Connect rather than directly from the sender's server. The sender's host sees a request from Connect, at a time Connect chose, with no browser fingerprint and no per-recipient identifier reaching your machine. Opening a message therefore does not tell the sender that a human opened it.

- **Status:** Available
- **Audience:** both
- **Channels:** email
- **In the app:** #/inbox
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/email/remote-images/

## What a remote image actually is

An image in an email is usually not in the email. The message carries an address, and the client fetches the picture when it draws the message. That fetch is a normal web request from the reader's network to the sender's server, and it carries the time, the address it was made from, and whatever identifier the sender put in the URL.

This is the entire mechanism behind read tracking. A one-pixel image with a unique address per recipient turns 'the client drew the message' into 'this person read it at this moment, from here'. Nothing about it requires script; it works in the strictest client because drawing a picture is exactly what a mail client is supposed to do.

## The request Connect makes instead

1. Sanitising rewrites each remote image address to a proxied one.
   - Result: The document handed to your browser contains no address belonging to the sender, so your browser never contacts them.
2. When the image is needed, Connect fetches it.
   - Result: The sender's server logs a request from Connect. It learns that something asked for that asset; it does not learn your network, your client, or your screen.
3. The bytes are returned to the screen through the proxy.
   - Result: The message looks the way the sender laid it out, without the confirmation the sender was hoping for.

> **Note** The identifier in the URL is still unique to you — that is the sender's design, not something a proxy can undo. What the proxy breaks is the link between that identifier and *your* moment of reading: the request no longer happens because a person looked.

## What this does and does not protect

| Signal | Reaches the sender? |
|---|---|
| Your IP address and network | No |
| Your browser and device fingerprint | No |
| The exact second a person opened the message | No |
| That the tracked address was requested at all | Yes — the request exists, it just is not yours |
| A link you deliberately click | Yes. A click is an action you took, and it goes where it says it goes |
| A reply you send | Yes, obviously — and that is the honest signal a sender is entitled to |

The last three rows are the reason this page exists rather than a claim of anonymity. Connect removes an involuntary disclosure. It does not pretend that corresponding with someone is private from them.

## When an image does not appear

- **The host is gone.** Old newsletters point at assets that were deleted years ago. The message renders; the box does not fill.
- **The host refuses the proxy.** Some servers answer only requests that carry a browser's own headers. Nothing is retried aggressively, because a retry loop against a stranger's server is a bad neighbour.
- **The asset is enormous or slow.** The proxy is not going to hold the screen waiting for a hero image.
- **It was an inline attachment, not a remote image.** Those come from the message itself and are covered on [Email attachments](/docs/email/attachments/).

None of these affect the reply. Drafting works from the text of the message; a missing decorative asset changes nothing. A missing asset that *was* the message — a quotation rendered as a picture, a scanned purchase order — is a real gap, and the thread is worth opening at the provider before approving anything.

## Questions

### Can I make images load directly for a sender I trust?

There is no per-sender exception documented, and adding one would put the decision on the reader at the exact moment the reader has least information. If you need the original asset, open the message in the provider's own client, where that choice is yours to make explicitly.

### Does the proxy cache what it fetches?

Caching behaviour is a property of `mail_render.py` and the serving path rather than something this page can state precisely. What is guaranteed is the part that matters: your browser is never the thing that contacts the sender.

### Does this help deliverability or spam scoring?

No. This is about inbound privacy on messages you receive. Whether your own outbound mail arrives is a different subject with different levers, set out on [Deliverability](/docs/email/deliverability/), and Connect never promises a delivery outcome.

## Related

- [Rendering HTML email safely](https://connectbyjbrh.com/docs/email/html-email/)
- [Email attachments](https://connectbyjbrh.com/docs/email/attachments/)
- [Conversation threads](https://connectbyjbrh.com/docs/email/threads/)
- [Deliverability](https://connectbyjbrh.com/docs/email/deliverability/)
- [Security and isolation](https://connectbyjbrh.com/docs/security/)

## What this page is based on

- CHANNELS.md §1 — rendering and privacy
- `backend/app/mail_render.py` — image rewriting
- Connect capability registry (docs-source/facts.py) — `html_mail_render`