Forem: William Weiner

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.