Connect by JBRH Open Connect

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 What this means
Audience
both
Channels
email
In the app
#/inbox
Last verified
Product version
6.3.2

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.

What this does and does not protect#

SignalReaches the sender?
Your IP address and networkNo
Your browser and device fingerprintNo
The exact second a person opened the messageNo
That the tracked address was requested at allYes — the request exists, it just is not yours
A link you deliberately clickYes. A click is an action you took, and it goes where it says it goes
A reply you sendYes, 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.

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, and Connect never promises a delivery outcome.