Small, annoying problem with a nice constraint-driven answer.
When you send a tracked email and then open it yourself — to check it looks right — that fires my tracking pixel. Now your "someone read it!" stat is inflated by... you. Every honest tracker has to solve this, or the numbers lie.
The obvious fix: record the opener's IP and ignore opens from the sender's IP. But storing recipients' IP addresses is exactly the kind of creepy-tracker behavior EmailKnow exists to avoid. An IP is personal data. I don't want it in my database at all.
So the constraint became the design: never store an IP, but still tell "this open is the sender" from "this open is someone else."
The trick is a one-way hash. At send time, I hash the sender's IP with a secret salt — SHA-256(ip + salt) — and store only that hash. When a pixel later fires, I hash that opener's IP the same way and compare. Match → it's the sender opening their own email → label it "self" and exclude it from the real-open count. No match → a genuine third party.
What's in the database is a hash, never an address. I literally cannot reverse it into "this person is in this city." I can only answer one yes/no question: is this the same source that sent the mail? That's all I need, and it's all I keep.
This is the pattern I keep reaching for on this project: figure out the single bit of information you actually need, and store the minimum that answers it — nothing that could answer more. "Is this the sender?" needs one comparison, not a location history.
The self-open exclusion is invisible when it works — your stats just quietly stop counting your own refreshes. The best privacy features are the ones nobody notices.
If you store any user identifiers: could you replace the raw value with a hash and still answer your actual question? I'm finding the answer is "yes" more often than I expected.
— building EmailKnow in public, #5
Top comments (0)