We're all told to never open spam emails, but lots of us don't see the harm. Surely so long as we don't click any links and we treat all information as untrustworthy then all should be OK?

Well, it's not actually that simple.

Read Receipt is a small web app which aims to demonstrate why simply opening a spam email can be dangerous - and why opening any email at all might be giving away more personal information than you might initially consider.

Before this article continues, I want to reiterate that Read Receipt stores literally zero information about the people that use it. It has no cookies, no databases, no logs, nothing; it's totally stateless. It's also fully open-source and the code can be viewed on my GitHub profile.

The Concept

Users who navigate to read-receipt.tobythe.dev are presented with a form where they can submit their email address. On submission of the form they instantly receive and email which contains a special type of image known as a 'tracking pixel'. These images are invisible, and they're present in more day-to-day emails than you might think. When your email client loads the image it makes an HTTP request to the server which is hosting the image, this gives away exactly when you opened the email, just like a read receipt in social media apps.

Using the Read Receipt web app, you can receive an email containing my implementation of a tracking pixel and when you open it, a second email detailing what information you just gave away!

Tech Stack

The website is a web app built using Angular 11. The app is server-side rendered for improved SEO and performance; this server-side rendering happens inside a Node.JS project running an Express app. The project is dockerised and hosted in Google's Cloud service Cloud Run and gets automatically re-deployed whenever there is a push to the master branch. The emails sent by the app are created using Handlebars and are sent using Amazon's Cloud service Simple Mail Service.

How can opening emails be dangerous?

As previously mentioned, opening an email containing a tracking pixel can inform the sender that you've opened their email. This is typically used in commercial settings where businesses can gauge the interaction levels with their marketing; however, it's also used by malicious actors for a couple of purposes.

The first problem is that by telling a malicious actor that you've opened their email, you've informed them that your email address is active. This lets them know that they should continue sending you spammy and dangerous emails in the hopes that they're able to trick you. It also indicates that your email address is more valuable when being sold as it's known to be active.

The second problem, which is arguably worse, is that when your email client makes the HTTP request to their server in order to load the pixel, it gives away personally identifiable information about yourself and you device.

Using the tool yourself will demonstrate to you what information you're simply giving away by opening emails, but in summary: the two dangerous pieces of information that my implementation relies on are your IP address and your User Agent.

IP Address

By giving away your IP Address you might be giving away more than you think. By using a third-party tool (ip-api.com in this case) Read Receipt can detect your approximate location and identify information about your connection like your ISP and if you're on a mobile connection or not. I once again suggest you use the tool to see just how accurately email senders know your location.

User Agent

Your user agent gives away information about the device you're using. Typically it can be used to determine which operating system you device runs and often which web browser you're viewing the email in. With this information hackers might be able to send you more targeted attacks that they know your devices are susceptible to.

How are times calculated when the app is stateless?

Those who have opened the emails from Read Receipt know that at the top of the second email it tells you when your first email was sent, when the second was sent, and the time difference between the two. This is possible without storing state in the app by instead storing state within the first email the tool sends you.

The URL for the tracking pixel in the emails sent out looks a little bit like this:

https://<domain>/email/<your email>/<timestamp>/pixel.png

By storing state in the URL within the email, I don't need to store anything myself and I'm still able to know who opened the email and when that email was sent.

The metadata being stored in the URL like that also helps prevent the tracking pixel from being served from caches as everyone's emails will contain different URLs.

It gets worse?

There's nothing dangerous about emails in particular which enables tracking pixels to work. All the information you give away by opening an email, you also give out every single time you visit any webpage. The purpose of the Read Receipt web app is simply to remind people what it is that they're giving away and to hopefully make some people more hesitant before opening emails from senders they don't recognise.