Skip to the documentation
Knowledge base

Tracking pixels stripped

The invisible image that tells a sender you opened their mail is gone before you see the message.

Details

  • Any image declaring itself 1×1 or 0×0 is removed server-side, along with the hidden preheader blocks that carry the same trick.
  • It runs on every message you open in the app, not on the way in. The stored copy is left as it arrived, and the stripping happens between that copy and your screen. There is nothing to switch on. Reading a message over the API or over MCP returns the stored copy as it arrived, so a client that renders that HTML itself is responsible for what it loads.
  • The rule is unconditional, and that is what makes it worth stating: OpenEmail sends mail that reports being opened (one switch for opens, another for clicks, and both of them ON unless the mailbox owner turns them off, so it is what a sender gets rather than something they went looking for), and the 1×1 image it appends is stripped out of an OpenEmail mailbox exactly like anybody else’s. So mail between two OpenEmail accounts never reports an open when it is READ. Printing it is the gap, because the print path does not run this pass and fetches the pixel with everything else. That is the cost of the rule rather than a hole in it, and exempting our own pixel is the one change that would make this page untrue.
  • Printing does not go through this pass, so a pixel survives into the printed markup. It obeys the remote-image switch below instead: with that switch off nothing in a printed page is fetched, and with it on, which is the default, printing loads remote images exactly as reading does.
  • A pixel that hides itself with CSS rather than with width and height attributes is not caught by this, and is caught by turning remote images off, which is the setting below, and the one that stops every remote fetch whatever shape it takes.