DEV Community: William Weiner

UID2: The Standard That Quietly Replaced the Tracking Cookie

William Weiner — Thu, 25 Jun 2026 04:10:53 +0000

While the industry celebrated the “death of the third-party cookie,” advertising platforms built a more persistent and standardized identity system based on your email address.

Unified ID 2.0 (UID2) is now powering a significant portion of open-web advertising. Created by The Trade Desk and open-sourced, it standardizes how companies turn email addresses into stable identifiers.

How UID2 Works

UID2 has two layers:

Raw UID2: A static SHA-256 hash (Base64) of your normalized email address. Deterministic and permanent — same email = same hash everywhere.
UID2 Token: An encrypted, rotating token used in the bidstream. This is what gets the “privacy-friendly” headlines.

The rotating token protects the bidstream, but the raw UID2 hash lives in backend databases across publishers, advertisers, and data platforms. That hash is the real backbone of the identity graph.

The Gmail Plus-Sign Trick Doesn’t Work Here

UID2’s normalization rules explicitly strip everything after the + sign for Gmail addresses (and remove dots). So user+shopping@gmail.com and user@gmail.com produce the exact same UID2 hash.

A common privacy workaround is rendered useless inside the UID2 ecosystem.

The Phishing Risk Nobody Talks About

Because the algorithm is fully public (no secrets, just SHA-256 + normalization), anyone can generate UID2 hashes from a list of email addresses.

An attacker with breached UID2 databases can now map which services you actually use and craft highly targeted phishing emails that impersonate those exact services. Hashing doesn’t anonymize — it creates a reproducible lookup key.

EUID (the European variant) improves consent flows under GDPR but doesn’t fix the underlying structural vulnerability.

The Alias Solution

The most effective defense is simple: never give sites your real email address.

Use unique aliases per service. Each alias produces a completely different UID2 hash with no mathematical link to your real identity or other aliases. This breaks the identity graph at the source.

EMail Parrot goes further by also stripping tracking pixels, unwrapping tracking links, and cleaning metadata at the relay layer before delivery.

Read the full article here:

UID2: The Standard That Replaced the Cookie

What are your thoughts on UID2? Is it a necessary evolution for a cookieless web, or does it introduce new privacy and security risks?

I’d love to hear from developers, privacy engineers, and ad-tech folks.

Who Is Email Security Actually Built For?

William Weiner — Sat, 20 Jun 2026 16:06:25 +0000

Email has one of the most mature security stacks in tech: SPF, DKIM, DMARC, BIMI, advanced spam filtering, and decades of infrastructure. Yet when you ask a simple question of each layer — who is this actually protecting? — a clear pattern emerges.

Authentication Protects Brands, Not Recipients

SPF verifies authorized sending servers.

DKIM cryptographically signs the message.

DMARC ties it all to the visible From: address and lets domain owners set policies.

These are excellent anti-spoofing and anti-counterfeiting tools. They protect the sender’s identity and brand reputation.

What they don’t do is ask: What is this authenticated message doing to the person receiving it?

A perfectly authenticated email (all green checks) can still contain:

Tracking pixels
Per-recipient rewritten links
Hidden identifiers
Fingerprinting techniques

The stack happily vouches for the authenticity of the surveillance.

DMARC’s Enforcement Bar Was Set Low on Purpose

When major providers finally pushed DMARC requirements in 2024, they mostly required the weakest mode: p=none (monitor only).

Meanwhile, the most common real-world spoofing attack — forging the display name while hiding the actual address — remains largely unaddressed. And the newest addition, BIMI, is essentially a paid brand-marketing feature that shows logos in inboxes.

The One Layer That Protects Recipients Is a Black Box

Spam filtering is the clear exception — it genuinely tries to protect recipients. But it’s also the only major layer that is proprietary, opaque, and controlled by the same gatekeepers who run the dominant email services.

This creates an interesting dynamic: open standards protect senders; recipient protection is a competitive moat.

The Envelope Is the Real Product

Below all the content-level protections lies the metadata — who emailed whom, when, how often, reply chains, message identifiers — which remains completely exposed. Even end-to-end encrypted email doesn’t protect the envelope.

This metadata has become extremely valuable in today’s data economy.

What Real Recipient-Side Email Security Would Look Like

If we designed email security for the person opening the message, it would be radically different:

Strip tracking pixels and rewrite links at the relay layer (before delivery)
Anonymize or replace per-recipient identifiers
Protect the recipient’s address as the core asset
Prevent reply-chain mapping across groups

This is exactly the direction we’re building at EMail Parrot — privacy-first group email that puts the recipient first.

Read the full article here:

Who Is Email Security For?

What do you think? Has the email security stack quietly evolved into a sophisticated brand protection + marketing infrastructure while leaving recipients exposed?

I’d love to hear perspectives from email deliverability engineers, privacy advocates, and security professionals.

The Cookie That Never Expires

William Weiner — Sat, 13 Jun 2026 20:26:00 +0000

You probably remember when the tracking cookie died. Browsers blocked them,
regulators demanded banners for them, and the advertising industry spent years
announcing its move to a "post-cookie world." It felt like a win for privacy.

It wasn't a win. It was a substitution. The identifier that replaced the cookie
is your email address.

Why your email address is a better cookie than the cookie ever was

A cookie lived in one browser on one device, and you could clear it whenever
you wanted. Your email address follows you everywhere. You type it into every
store, newsletter, app, loyalty program, and login screen. It is the same on
your phone, your laptop, and your work computer. It survives for decades.

The advertising industry noticed. The standard practice today is to take the
email address you provide, run it through a hashing function, and use the
result as a tracking identifier. The industry calls this a "hashed email" and
describes it as privacy-safe because the hash can't be reversed back into your
address. What that description leaves out: it doesn't need to be reversed.
Every company that hashes your address gets the same code. The code IS you.

This is not a fringe practice. It is the documented foundation of the
post-cookie ad industry. Identity resolution vendors openly sell
email-centric identity graphs
built on exactly this matching. Marketing platforms publish guides on
unlocking the hashed email "goldmine"
sitting in customer databases. Analytics tools document how
clicking a newsletter link that carries your email hash
stitches your devices together into one profile. None of this is hidden. It is
the product.

So here is the trade you actually made when the cookie died: an identifier you
could clear in two clicks was replaced by one you've used for fifteen years
and gave to everyone.

What the graph knows

Once your email address is the key, everything keyed to it can be joined. The
shoes you browsed on your laptop connect to the news you read on your phone.
The purchase you made in a store, where the cashier asked for your email "for
the receipt," joins the profile too. Data breaches add their contents to the
pile -- and your address has almost certainly been in several.

It gets one step stranger. Marketing emails carry per-recipient trackers --
invisible images and rewritten links that identify you specifically. When you
forward one of those emails to a friend and they open it, their device
announces itself against your tracking identifier.
Email platforms acknowledge
that forwarded opens register against the original recipient. The email you
shared becomes a signal that the two of you are connected and what you both
found interesting. Academic researchers studying email tracking found that
a substantial share of commercial emails leak the recipient's address -- often
in hashed form -- to third parties the sender never mentioned.

Is your email address personal information? Both GDPR and CCPA say yes,
plainly. But the legal classification understates the situation. Your email
address is not just a piece of personal data. It is the join key -- the one
identifier that links all the others together.

You can't clear it -- but you can stop using it

You can't reset your email address the way you cleared cookies. Changing it
means losing access to everything attached to it, which is exactly why it
makes such a durable identifier.

What you can do is stop handing the join key to everyone who asks.

If the email address is the cookie, then an alias is the cookie blocker. Give
every company a different address that routes to your real inbox, and the
hashes stop matching. The store, the newsletter, and the loyalty program each
hold a different code, and the graph can't join them. You stay reachable --
real mail still arrives, replies still work -- but the one thread tying your
profiles together is gone.

That is half the answer. The other half is the trackers inside the email
itself, because an alias does nothing about the invisible image that reports
when you read a message. Those have to be removed before the email reaches
you -- which means stripping the tracking machinery and rebuilding a clean
copy for delivery. An email that has been through that process can even be
forwarded to a friend without reporting on them when they open it.

The cookie didn't die. It moved into your email address. Treat that address
accordingly -- like the permanent identifier it has become, not like a piece
of contact information.

Originally published at emparrot.com.

What a Mailman service shutdown reveals about the state of mailing lists in 2026

William Weiner — Wed, 10 Jun 2026 23:32:20 +0000

DreamHost is shutting down their hosted Mailman service on July 31. If you run a
list there, you already know. If you don't, it's worth understanding why -- because
the reasons behind the decision say something about where mailing list infrastructure
stands today.

I'll be upfront: I built EMail Parrot, a privacy-first mailing list relay, and this
situation is relevant to us commercially. I'm going to try to write something useful
regardless of that.

Why DreamHost's exit makes technical sense

Mailman is roughly 25 years old. That longevity is a credit to the project, but it
also means the software was designed for a threat environment that no longer exists.

The original Mailman model assumes email is mostly plain text and that threats are
simple and human-detectable. In 2026:

HTML email is the norm, and with it comes an entire passive tracking surface -- pixels, CSS-based trackers, fingerprinting links -- that Mailman passes through without inspection
Member email addresses are visible in headers and exposed to senders, creating a persistent privacy risk that list admins have no control over
There is no systematic inspection of URLs, attachments, or message content beyond whatever external spam hooks an admin has configured
Monthly subscription reminders go out in plain text including passwords -- a detail that looks almost quaint now but is a real credential exposure vector
When a member's account is compromised, the attacker inherits their list membership, subscription details, and a window into other members' activity. The blast radius of a single member compromise can extend across the entire list.

AI-generated threats add another layer. Mailman has no framework for detecting
AI-generated phishing at volume, and prompt injection -- malicious instructions
embedded in email content to manipulate AI agents processing a recipient's inbox --
is an emerging threat class that list software built before LLMs existed was simply
never designed to consider.

Running that stack on modern cloud infrastructure requires maintaining a deployment
model that was never intended for it. The operational cost to benefit ratio for a
hosting company is poor and getting worse.

The digest question

The most common concern from people looking at alternatives is digest delivery. It
is worth examining whether that concern is pointing at the right thing.

Digest was a solution to two problems: mail server storage costs and inbox overload.
In 2026, mailbox storage is essentially free. Every major email client supports folder
filter rules -- route list mail into a dedicated folder, check it when convenient,
reply normally with threading intact. The underlying problems digest solved are already
solved by better means. Most people reaching for digest are actually reaching for inbox
control, and they have better tools for that than a 25-year-old batching mechanism that
introduces reply-address complications.

What the alternatives actually are

If you are helping someone migrate off DreamHost Mailman, the honest framing is this:
most mailing list alternatives follow the same basic architecture Mailman established.
Member addresses visible, messages passed through unexamined, digest as inbox
management. Google Groups, Groups.io, and most others are a hosting change, not a
model change.

Hosted Mailman (mailman3.com,
mailmanhost.com) is the right answer for people who need
minimum disruption and can accept the existing model's tradeoffs.

EMail Parrot is a different architecture: the relay is an active participant rather
than a passive pipe. Every message is rebuilt from scratch after stripping tracking
content, member addresses are replaced with pseudonyms, and content is scanned before
delivery. It is not a drop-in Mailman replacement -- it requires pseudonyms at import
and does not host archives -- but it was designed for the current threat environment
rather than the one that existed when Mailman was written.

Migration guide for Mailman users: emparrot.com/mailman-migration.html

The business lesson

One more thing worth noting since it comes up in any discussion of sunsetting
software: DreamHost's execution here has been poor. Short notice, no migration
support, thin communication. The customer frustration has spread from the Mailman
conversation into broader discussions about DreamHost as a company.

How you exit a service matters as much as whether you exit it. That is probably
obvious but the evidence keeps suggesting it needs to be said.

Email Privacy Shield: Zero Direct Mail and No Cross-Site Correlation via Email Aliases

William Weiner — Sun, 26 Apr 2026 19:25:38 +0000

Every alias service hides your address. Almost none of them fix what happens after you reply. Give out your real address once, and it becomes a permanent identifier that data brokers, marketers, and attackers can correlate across services, sites, and breaches. Reply chains and headers often leak context. Tracking pixels and sophisticated passive techniques confirm opens and clicks even before you interact.

Developers face this acutely: every SaaS signup, API provider, cloud account, or open-source contribution risks linking identities.
One leaked address can map your entire digital footprint.

A robust countermeasure is the Personal Privacy Shield - a compartmentalized setup using Email Parrot that ensures your real inbox receives no direct mail from the outside world. Every external contact (service, person, or business) gets its own unique email alias address. All inbound traffic routes through a relay that applies deep privacy protections before delivery.

I work on EMail Parrot and run variations of this pattern personally. It mirrors the "unique password per site" principle but applied at the email layer.

Why a Relay with Virtual Private Email (VPE) Matters

Simple email forwarding or alias services often fall short.
They may hide the real address but lack comprehensive relay-layer processing:

Header scrubbing and propagation attacks: Email headers and reply chains can embed identifiers that allow network graphing and cross-message correlation. A proper VPE relay replaces sender identifiers with one-way hashes under its namespace, preserving threading while blocking reversal or mapping.
Tracker removal beyond pixels: Client-side tools (browser extensions or email client blockers) act after delivery and miss reply-chain elements or evolving techniques. Relay processing sees the full message and can strip both active trackers (e.g., HTML and CSS-based external references, presentation attributes that trigger fetches on render) and passive ones (e.g., tokenized query parameters in links, click redirects).
Blast radius reduction: If one alias leaks or gets spammed (via breach or sale), it affects only that compartment. Quarantine or delete it instantly without touching other contacts or your core address.

Virtual Private Email (VPE) turns an open list into a privacy envelope.
Outbound messages to externals use a special addressing pattern so recipients see only the alias, never the real address. Replies route back automatically through the correct alias, with all messages filtered for spam, viruses, and trackers.

This setup is not just forwarding - it is a structural firewall that client tools cannot replicate due to limited visibility into full message context and outbound paths.

Step-by-Step Setup (~15-20 Minutes)

Configure Email Parrot

Go to emparrot.com/admin and create a new list with a neutral name (e.g., relay or mp). The list address becomes something like relay@emparrot.com.

Add yourself as the sole member using a neutral pseudonym (e.g., me).

In Group Settings, enable Open Email List with VPE (Virtual Private Email). This enables private outbound initiation and reply routing.

Create a dedicated sublist (unique alias) for each external party or category. Examples:

github.relay@emparrot.com

aws.relay@emparrot.com

stripe.relay@emparrot.com

doctor.relay@emparrot.com

temp1.relay@emparrot.com (for throwaway signups)

Each sublist contains only you. Use short, opaque names to avoid leaking context.

Enable all protection layers in Group Settings:

Advanced protection
Strip external content
AI safe protection
Instant deletion

Lock Down the Real Inbox

Configure your email client to block non-relayed mail.
For Gmail:

Filter condition: -from:emparrot.com
Action: Skip Inbox, apply label "Direct - Review"

Legitimate traffic from Email Parrot arrives normally. Everything else (scams, leaks, direct sends) goes to a review folder. For extra defense-in-depth, point the relay to a never-used-before address at a privacy-focused provider like Proton Mail or Tuta.

Optional: Add per-alias filters to route mail into dedicated labels/folders for better organization.

Outbound Communication and Replies

For new contacts: Use the VPE format via the address conversion tool at emparrot.com/ext-email.html.

For replying to email: The reply-to field of EMail Parrot emails will always have the address configured to route back through the service at the alias the email came through.

Save the converted address in your contacts. The external party sees only the alias. Replies return routed through the same identity, fully protected.

Never share your real address.

Developer Advantages

No cross-service correlation: GitHub, cloud providers, payment processors, and forums each interact with isolated aliases.
Leak detection: Spam on one alias reveals exactly which party leaked/sold it.
Address book safety: Commands like addressbook.relay@emparrot.com return only pseudonyms and sublists - harmless in this solo setup.
Custom domain option (available via upgrade): Makes aliases appear more native (e.g., under your own domain) and slightly harder for automated identification as relays.

Find Out More

The complete checklist and additional notes are in the official guide:

Setup: Personal Privacy Shield (https://emparrot.com/setup-max-privacy.html)

If you are running your own alias/relay experiments or privacy stack in 2026, what techniques have you found most effective against modern tracking vectors? Share in the comments - curious to hear other devs' approaches.

Tracking, Propagation Attacks, and What We Found in Real Email Traffic

William Weiner — Thu, 09 Apr 2026 20:07:24 +0000

A few weeks ago I posted about finding the same per-recipient identifier in three independent places inside a single marketing email -- pixel, click redirects, and technical headers -- and asked what other vectors people had seen.

Surveying surfaced some good ones: CSS media queries, hidden data attributes, MIME boundary patterns. I went looking. Here is what I found in real production traffic, and what turned out to be harder to close than expected.

1. CSS Tracking Is Broader Than I Thought

The original post focused on <img src=> pixels and click-redirect wrappers. CSS-based tracking is a separate attack surface that image-blocking tools don't touch, and it is more varied than the obvious background-image case.

The obvious case (external stylesheet link):

<link rel="stylesheet"
  href="https://tracker.esp.com/open/PERRECIPIENTTOKEN.css">

When the email client loads this stylesheet, the sender's server logs the open. The member never sees this. Apple Mail Privacy Protection pre-fetches images but not stylesheets, so this survives MPP.

The less obvious cases:

/* @import in a <style> block */
@import url('https://tracker.esp.com/t/PERRECIPIENTTOKEN.css');

/* Any property that accepts a URL, not just background-image */
li { list-style-image: url('https://tracker.esp.com/PERRECIPIENTTOKEN'); }
div { border-image: url('https://tracker.esp.com/PERRECIPIENTTOKEN'); }

The one I did not expect -- CSS custom property indirection:

:root {
  --emp-track: url('https://tracker.esp.com/PERRECIPIENTTOKEN');
}
p.hero::before {
  content: var(--emp-track);
}

The tracking URL is stored in a custom property and referenced indirectly. A filter that looks for url( in property values like background-image will not find it here. The custom property declaration looks innocuous; only following the reference chain reveals the external URL.

I have not yet seen this in a real email, but it is a documented evasion technique in 2025-2026 security research and straightforward to generate from a template.

Beyond CSS: HTML presentation attributes

These are not CSS at all, which is why they were a separate discovery. HTML has legacy presentation attributes that also trigger automatic network fetches:

<!-- table background attribute -- HTML4 era, still renders in many clients -->
<table background="https://tracker.esp.com/PERRECIPIENTTOKEN">

<!-- video poster -- loads even if the user never plays the video -->
<video poster="https://tracker.esp.com/PERRECIPIENTTOKEN" src="...">

<!-- object/applet legacy attributes -->
<object data="https://tracker.esp.com/PERRECIPIENTTOKEN">

The background= table attribute is the one I actually found in production email. It is visually identical to a background set via CSS, but the attribute lives outside any style block and is missed by a CSS-only filter pass.

2. The Reply Chain Attack: Propagation Tracking

This one came up as I was working through the threat model and it is arguably more valuable to trackers than open tracking.

The setup: When a sender issues an email, their ESP assigns a Message-ID that typically contains per-send and per-recipient tokens:

Message-ID: <campaign.abc123.recipient.def456@esp.example.com>

When a member replies to that email, their client includes the original Message-ID in the References header:

References: <campaign.abc123.recipient.def456@esp.example.com>
In-Reply-To: <campaign.abc123.recipient.def456@esp.example.com>

If the sender has instrumented their receiving infrastructure to parse incoming References headers, they can:

Recognize their own campaign token (campaign.abc123)
Recover the per-recipient token (recipient.def456)
Link the reply back to the original send record

This maps who replied to whom. For a relay service like the one I run, the risk is amplified: if a member receives a tracked email through the relay and then replies, the relay's outbound message carries the original sender's Message-ID in the References chain. The original sender now knows the reply chain came through a relay and what user emails it came through.

The fix is to hash all sender-issued Message-IDs in the outbound References and In-Reply-To headers before delivery. The hash is irreversible (sender cannot recover the token), consistent (same input always produces the same output, so member-side threading still works), and emitted under your own namespace so it cannot be confused with any other IDs. This rewrite is valid to do since this code is for an email relay, not an email forwarding service.

# Original References in outbound reply -- before fix
References: <campaign.abc123.recipient.def456@esp.example.com>

# After hashing
References: <emp-a3f9b2c1d4e5f678@emparrot.com>

Our delivery IDs pass through unchanged -- members thread on these and they contain no sender-controlled token.

3. Direct-Destination URL Tokens (No Redirect Needed)

The original post covered click-redirect wrappers: links rewritten through a tracking server before reaching the real destination. There is a simpler variant that bypasses the redirect entirely.

Real example from a Nextdoor email (April 2026), every link included:

https://nextdoor.com/news_feed/?ct=ABCDEF123&ec=GHIJ456&token=UNIQUE789&auto_token=XYZ012&link_source_user_id=345678

The destination is real (nextdoor.com). There is no redirect. But the per-recipient token is in the query string and fires on click. Class A redirect unwrapping does not catch this because there is nothing to unwrap -- the destination IS the URL.

The naive fix is a known-bad-parameter blocklist (utm_*, fbclid, etc.), but that loses the arms race: senders rename parameters or use unfamiliar ones. Nextdoor's ct=, ec=, auto_token=, and link_source_user_id= would not appear on most blocklists.

The approach that works without needing to be right about every parameter: strip all query parameters from all links, and back up the original URLs in an attachment when non-utm_* parameters were present. The stripped link is the primary path. The backup attachment is a recovery mechanism for action links (unsubscribe, confirm) where tokens may be functionally required.

# Link in email body after stripping
https://nextdoor.com/news_feed/

# emparrot-original-links.txt attachment
[View your feed] https://nextdoor.com/news_feed/?ct=ABCDEF123&ec=GHIJ456&...
[Unsubscribe]    https://nextdoor.com/email/unsubscribe/?token=UNIQUE789&...

The utm_* parameters are stripped silently with no backup -- the destination always works without them.

4. Meta Tag Token Embedding

Several other examples exploited data attributes. Meta tags turned out to be a closely related case worth separating out.

<meta name="x-em-id" content="PERRECIPIENTTOKEN">
<meta name="campaign" content="CAMPAIGN123/PERRECIPIENTTOKEN">
<meta name="list-id" content="LIST456/MEMBER789">

These do not trigger a network fetch. They are completely invisible to image-blocking tools and to users. But they survive into quoted reply content -- if a member replies and includes the original email body, the quoted section carries these meta tags forward.

The threat model is the same as the References header case: the sender's receiving infrastructure can recognize their own tokens in the reply and reconstruct network information without ever seeing an address.

The fix is a whitelist. The set of meta tags that have any legitimate function in email is small and stable: charset, viewport, http-equiv for content-type, format-detection, color-scheme, theme-color, description, author, generator, robots. Strip everything else.

5. What Turned Out to Be Hard

CSS media query conditional loading -- The vector is real:

@media (prefers-color-scheme: dark) {
  body { background-image: url('https://tracker.esp.com/dark/PERRECIPIENTTOKEN'); }
}
@media (prefers-color-scheme: light) {
  body { background-image: url('https://tracker.esp.com/light/PERRECIPIENTTOKEN'); }
}

This leaks dark/light mode preference in addition to confirming the open. I have not seen this in a real email yet, but it is described in 2026 privacy research as an emerging pattern. The fix is the same (strip external URLs from all CSS properties) but the threat is worth naming: it is not just "did they open" but "what device profile are they using."

Body structural fingerprinting is the vector I cannot close without semantic understanding of the content. Unique per-recipient signals embedded in the body itself: specific inline color values, attribute ordering, whitespace patterns, synonym substitution. These survive into reply quotes and surface unexposed users when those replies propagate. Partially mitigated by hashing CSS class names (destroys class-based fingerprints in quoted content), but full removal is out of scope.

Class B opaque link IDs (c.gle, click.mailchimp.com, and similar) cannot be resolved without fetching the tracking URL, which would itself be tracked. The right behavior is to flag these with a warning before the member clicks rather than attempting to unwrap them. Fetching to resolve is not an option.

What We Shipped

For full disclosure: I built these fixes into the relay service EMail Parrot. The analysis above drove the release this month. The implementation handles all of sections 1-4. Body structural fingerprinting and Class B unwrapping remain open.

A writeup of the release is at the EMail Parrot blog if that is useful context: Pixels Were Just the Beginning

New Questions for the Community

The original post asked about CSS media queries, hidden data attributes, and MIME boundary patterns. The first two turned out to be real and addressed above. MIME boundary patterns remain on the list.

A few things I am still thinking about:

MIME boundary reuse: Is there evidence of ESPs using predictable MIME boundaries that encode per-recipient data? I have not seen it in real traffic but it seems plausible. Our relay rebuilds the email from scratch and replaces all MIME boundaries so this threat is architecturally not present for EMail Parrot.
Quoted-printable encoding patterns: Can per-recipient tokens be embedded through deliberate encoding choices (encoding specific characters to =XX form or not) that survive relay and appear in quoted content?
cid: Content-ID attributes: MIME attachment Content-IDs are sender-chosen. I am treating this as low risk but would be interested in evidence either way.
plain-text URL tracking: Class A redirect URLs appearing in plain-text body parts rather than HTML hrefs. Lower priority since plain text is less common in tracked email, but not zero.

Has anyone seen these in the wild? And are there vectors I have missed entirely?

Cross-posted from the EMail Parrot engineering blog. I am the sole developer of the service and this work grew directly out of the threat analysis in the original post.

Beyond Pixels: How Modern Emails Embed the Same Identifier Everywhere

William Weiner — Thu, 02 Apr 2026 19:58:01 +0000

A few days ago I received a promotional-style email asking for lobbying help on upcoming state regulations on email privacy of all things. Instead of clicking through, I opened the raw source and found something interesting.

The same unique tracking identifier (tied to me as the recipient) appeared in three completely different places inside that single message:

A classic invisible tracking pixel (the 1x1 image that phones home when the email loads).
Every clickable link, rewritten through a tracking redirect with long, unique tokens.
Technical email headers that would survive even if the message was forwarded or relayed.

This wasn't an isolated case. I had just finished analyzing a different marketing email that showed the exact same pattern. It looks like the email tracking arms race has quietly entered a new phase.

The Old Way: Just a Pixel

For decades, open tracking relied almost entirely on the humble tracking pixel: a tiny invisible image hosted on the sender's server. When your email client loads remote images, the server logs the open, your approximate location (via IP), device, and timestamp.

Privacy features have made that method much less reliable:

Apple’s Mail Privacy Protection pre-fetches images through proxies.
Many users and organizations disable remote image loading by default.
Gmail and other clients now warn about or limit external content.

So senders adapted.

The New Pattern: One Identifier, Multiple Vectors

Instead of depending on a single fragile signal, modern templating systems now embed the same per-recipient identifier across several independent channels. The goal is redundancy: if one vector gets blocked, others still report back.

Here’s what I’ve been seeing in real emails:

Header-based identifiers: Custom or structured headers (such as Feedback-ID, patterned Message-ID values, or other metadata) contain campaign or recipient tokens. These live outside the visible body and often survive forwarding, relays, and even some stripping tools.
Click-tracking links: Every (or nearly every) link gets wrapped through a redirect service. The URLs contain long, seemingly random character strings or encoded parameters that uniquely identify the recipient and the specific link clicked. Even if images are completely blocked, a click still phones home.
The traditional pixel: Still present as a fallback — usually a 1x1 image with its own unique token in the URL.

In the examples I examined, the same underlying identifier (or closely derived values) appeared in all three locations. That means the sender can correlate:

Whether the email was opened (pixel or header signal)
Which links were clicked (redirect tracking)
And tie everything back to the original send record, even across forwarded or relayed copies.

This layered approach makes passive tracking much more resilient.

Why This Matters

Many people assume “I just disable images and I’m safe.” That no longer holds when the identifier lives in headers and link wrappers too.

These techniques show up not just in obvious marketing blasts, but in other unsolicited commercial or advocacy emails as well. The infrastructure is baked into popular email service platforms and marketing tools, so even senders who aren’t deeply technical may be using it by default.

How to Spot It Yourself

In Gmail: Three dots → “Show original”
In most other clients: Look for “View message source” or “Raw message”
Search for:
Long random-looking strings in Feedback-ID, Message-ID, or other X- headers
<img src= pointing to external domains with query parameters
href= values that go through known redirect domains or contain long encoded segments instead of clean destination URLs

If you see matching or closely related tokens across headers, pixel URLs, and link wrappers, you’re looking at this multi-vector pattern.

The Bigger Picture

Email senders face real pressure: privacy features are reducing the reliability of traditional metrics, while regulators continue to tighten rules around tracking and consent. The response has been to spread the same identifier across more places so the signal doesn’t die when one vector is defeated.

This arms race is likely to continue. As clients and privacy tools get better at blocking one method, new or hybrid vectors will appear.

Full disclosure: I’m the developer of a privacy-focused email service that rebuilds messages to reduce tracking exposure. This analysis grew out of work on improving detection and removal of these hidden vectors. The observations here are based on raw email inspection and stand independently of any product.

What Do You Think?

Have you noticed similar multi-vector tracking in everyday emails (marketing, transactional, or otherwise)?
Are there other subtle techniques (CSS media queries, hidden data attributes, MIME boundary patterns, etc.) you’ve seen that aren’t covered above?
How aggressively should email clients or privacy tools try to neutralize header-based and link-wrapper tracking?

I’d love to hear examples or counterpoints in the comments. If there’s interest, I can share more sanitized raw-source snippets or dive deeper into specific vectors.