Mailtrack

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me email tracking that replaces Mailtrack — and read the first paragraph before you decide to, because this one deserves an argument rather than a specification.

Read this first. This category tells you when somebody opened your message, using a pixel they did not agree to and cannot see. It is surveillance of a private act, it is why mail clients now block remote images by default, and in several jurisdictions doing it without consent is unlawful. The numbers it produces are also largely fictional now: privacy proxies pre-fetch every image, so a large share of 'opens' are a machine, and a genuine reader with images off never registers at all. So build the version that is defensible — link tracking on your own domain, aggregate reporting, and consent where it is required — and skip the pixel, or use it knowing exactly what it is.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A browser extension if you want the status inside your inbox, talking only to your own server
- Caddy in front

THE DATA MODEL
- messages: id, external_message_id, subject, to_hash, sent_at, campaign, consent_basis, tracking_kind
- links: id, message_id, original_url, token, position
- clicks: id, link_id, at, ip_hash, user_agent_bucket, is_probable_bot
- opens: id, message_id, at, ip_hash, user_agent_bucket, is_probable_proxy — only if you decide to use a pixel at all
- Recipients stored as a salted hash unless you have a reason to hold the address, and the reason written down

LINK TRACKING, WHICH IS THE DEFENSIBLE PART
- Every link rewritten through your own short domain and redirected with a 302, never a 301 — a permanent redirect cached in a client can never be corrected
- The redirect answers in a couple of milliseconds and records after responding
- A click is a real action taken by a person. Unlike an open, it means something
- Bot filtering: security scanners in corporate mail follow every link in a message within seconds of delivery. Discard clicks that arrive implausibly fast, that come from a datacentre range, or that hit every link in one message at once — otherwise your click rate is measuring an antivirus product
- Never rewrite an unsubscribe link, and never rewrite a mailto

IF YOU USE A PIXEL AT ALL
- Say so in the message. One line in the footer stating that opens are recorded — that is what turns this from surveillance into telemetry
- Treat the number as a lower bound with a wide margin, and label it that way everywhere it appears
- Discard opens that arrive within a second of sending, from known proxy ranges, or repeatedly from the same address hash in a burst
- Never a per-recipient notification saying somebody just read your message. That is the feature that makes people uncomfortable, and it is the one worth leaving out

CONSENT AND THE LAW
- For marketing mail in the EU and the UK, tracking is processing personal data and needs a lawful basis, usually consent gathered at signup
- Record the basis per recipient, with the date and the wording they agreed to
- A recipient who asks not to be tracked is not tracked, and that preference outranks every campaign setting
- One-click unsubscribe in every message, and the List-Unsubscribe headers
- This is not legal advice; get some before running this against a real list

WHAT TO REPORT
- Clicks per link, per message, per campaign, unique and total, with the bot filtering applied and the count of what was filtered shown
- Opens, if collected, in aggregate only, with the caveat printed beside the number
- Trends over time, which are more meaningful than any single figure
- Never a screen that shows one named person's reading behaviour. Aggregate is enough for every decision this data supports

THE EXTENSION, IF YOU BUILD ONE
- Reads your own server, shows status beside a thread, and talks to nothing else
- No permission wider than the one host it needs
- Say in its own description exactly what it does and what it sends

WHAT TO REFUSE TO BUILD
- Notifications when a specific person opens a message
- Location from the opener's address, which is inaccurate and creepy in equal measure
- Reading duration, which is guesswork dressed as data
- Any of it applied to a personal message. A newsletter is a broadcast; a message to one colleague is a conversation, and instrumenting a conversation is a different thing entirely

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, HASH_SALT, SESSION_SECRET, SHORT_DOMAIN
- Migrations on boot, each once
- A stated retention with a sweeper that actually deletes
- Nightly backup off the machine, restore script
- Health endpoint

WHAT MATTERS MOST
Bot filtering and the honesty of the numbers. Build link tracking with the scanner filter first, and put the caveat next to every figure. If you build the thing well, you will find you have replaced a product that promised certainty with one that tells you the truth — which is less satisfying and considerably more useful.

Give me the repository, migrations, .env.example, the link rewriter, and a README that opens with the argument above and states the legal position for the places you operate.