Ask HN: How do some email clients track 'who read' the email?

17 points by epimetheus2 ↗ HN
This is puzzling me.

Even if there are multiple receivers, `to`, `cc`, `bcc` there are some companies that in their client tell you exactly who opened it.

How is it implemented? I always assume these trackers use some hidden pixel image when sending emails - but how can they trace the exact person who opened the email?

15 comments

[ 3.7 ms ] story [ 37.4 ms ] thread
> I always assume these trackers use some hidden pixel image when sending emails - but how can they trace the exact person who opened the email?

Apparently they use a hidden pixel, i.e. a separate tracking code, for each recipient. There was a discussion about this feature in Super Human: https://blog.superhuman.com/read-statuses-bdf0cc34b6a5

how would that work? so every recipient would receive different email content with different pixel?
Yep. Each user gets an email unique to them.
wouldn't then CC, BCC and TO headers not fit? and emails form different thread, i.e. in gmail?
The headers are totally irrelevant for the actual delivery of the mail. For delivery the so-called envelope is relevant (MAIL FROM, RCPT TO).
Sort of. It doesn't have to be a traditional file or anything, so it helps to think of it as a unique URL being accessed instead of a different pixel. What makes it work is the client automatically loading all images, which means the user accesses the URL automatically as well. It stops working if the client uses features that disable automatic image loading.

You could implement this by sending each email with an img tag that has a unique url, such as https://foo.bar/baz/id_1.jpg, which the server will route under the hood to a script. The script stores the fact that someone visited id_1, assumes it must have been the recipient since only they have the URL to get to it, and responds with image data to make the whole thing seamless.

Correct, even if you look at the URL on each link it will have IDs and tracking code embedded to be able to see who clicked what link and very rarely go straight to the actual URL it is referring to without a hop or two.
Embed some piece of HTML that calls back to the URL of an external server. Each recipient gets a slightly different URL. So when the email client parses <img src="server<dot>com/emailtracker.php?id=abcd"/> it connects to server<dot>com/emailtracker.php and passes your ID (abcd) to the emailtracker.php page.

Then some code in emailtracker.php finds your ID in a table of ID's issued by sent emails and records your IP and browser fingerprint alongisde the ID they issued you when they sent the email.

Nowadays most email providers and clients like Thunderbird block non-local images for this reason.
This should not work if your email client is configured to not load the images.
I read emails as raw text. I wrap mine so your eyes don't travel too much horizontally.
In the good old days when one could telnet to SMTP servers, you could input several RCPT TO commands to define multiple recipients. I would guess all of the recipients would receive the exact same email.

This reference also shows https://www.samlogic.net/articles/smtp-commands-reference.ht... that you can define a "To:" header field, so even though the client shows "This email was sent to the following people" (by parsing the "To:" header), there's technically nothing stopping the mail client to lie in the header about who the mail was sent to. Or that 2 recipient could get 2 different versions of the e-mail.

I guess the mail client crafts a unique email (with a unique tracking pixel URL) and addresses it (via RCPT TO) to a unique recipient, but in the "To:" header it will specify all the recipients, claiming "Each of the following people got an exact copy of the e-mail".

Easiest way is a 1x1 tracking pixel that basically sends an ACK back to the sender when it loads. It can also resolve information about the recipient of the email from databases the mailer has from previous campaigns along with people intelligence search engines like Sparkpeople and Pipl.

However, that requires the client having HTML email enabled, which most of them do (since most don't care about that sort of stuff).

The other way is by using a BCC, since MTAs will route the email to them but do not display it back to the client. However, some email servers can filter based on bcc's, and I'm guessing that this is illegal.

Email client generates a read receipt.