“Oh yeah, I can see that she read my email at 3.42PM today.” That was probably what my roommate told me about two years ago.
“Wait what? How did you know that?” I queried. Having a read receipt is not the norm when it comes to emails.
“My email client tells me that,” he said. What? Have I been doing emails wrongly this entire time?
Turns out, I wasn’t crazy and my roommate have been using an app that turns email threads into chat logs. This software tells him the exact time his recipients opened his emails.
This article is organised as follows:
- On this page: How are email read receipts achieved?
- On the next page: Is this feature brilliant or privacy-invading? How to stop it?
Part 1: The How
Those of us who used chat applications will be no strangers to delivery and read receipts. You can largely thank WhatsApp for popularising it, which has the most number of monthly active users as of October 2019, according to statista2.
- Single tick. Message is sent.
- Double ticks. Message has been received by recipient.
- Blue double ticks. Message has been read.
Of course, I’m not suggesting that chat apps introduced this concept; proof of deliveries have long predated electronics –– postal entities in the 18th centuries offered this service3, where the recipient could sign a paper which is returned to the sender.
Similarly, this idea transfers over to the electrical counterpart with return receipts implemented in two forms: message disposition notifications (MDNs) and delivery status notifications (DSNs). A third type using web beacons are also typically employed by companies and trackers.
Turns out, my roommate’s app was using web beacons, but let’s go through all three of them!
Message Disposition Notifications (MDNs)
According to RFC22984, MDNs are for humans and mail clients to track what happened to a message, in particular:
- The mail client has displayed the mail content, which the recipient might or might not have read.
- The mail was forwarded.
- The mail was successfully sent to a mailing list exploder.
- The message could be seen or not, but was deleted. The deleted message can still be restored and read.
- The recipient can setup their mail client to always deny the MDN requests. Alternatively, they can silently ignore the requests.
- A required parameter is not understood by the mail client.
MDNs are entirely advisory –– The sender requests return receipts via email header with
X-Confirm-Reading-To:, but the recipient email client can ignore the requests. The recipient can set up the mail client to respond manually or automatically.
Delivery Status Notifications (DSNs)
A DSN receipt allows a sender to know if the recipient’s mail server received the message. As it does not imply that amessage has been or will be read, it is less intrusive of the recipient’s privacy, and thus nearly all servers support it5 but may choose to ignore DSN requests partly as a measure to counter spam. Therefore, a DSN receipt is also not guaranteed.
According to Lifewire6, DSN first existed as part of RFC8217 to notify that a delivery has failed. However, the absence of such a notification does not mean that the delivery is successful, and thus an extension was proposed as part of RFC18918.
For each recipient, you can request which DSN is desired:
- Success (can be combined)
- Send a notification if the mail was delivered.
- Failure (can be combined)
- Send a notification if the mail was not delivered.
- Delay (can be combined)
- Send a notification if the mail delivery was delivered unexpectedly, but the actual delivery outcome is not determined yet.
- Never (must be standalone)
- Do not send any DSN.
Instead, as emails support HTML, the marketers can link to an external image or resource which needs to be fetched when the email is read. However, these images have unique links such that when you load them, the marketers were able to link the activity to you. In more details:
- Marketers generate a unique image link for each email address they are sending to, and these are all recorded in their database.
This does not mean they need millions of copies of images, a simple GET request will do the job. For example, the link
https://marketer.com/picture.jpg?12kjh32is generated uniquely for
- The user opens the mail and the client automatically loads external images. This GET requests
12kjh32tells the marketer:
- The fact that you opened the mail (or that the email address definitely exists).
- The time(s) at which you opened the mail, and how many times you opened the mail.
- IP address (information on country and general location).
- User Agent (information on your OS, internet browser name and version).
- Whether you forwarded the mails.
I asked my roommate to send me an email and this is what mail clients would show. Notice that ProtonMail reports that no trackers were found.
This is the HTML of the email body (partially censored):
<div dir="LTR"><div dir="auto">Hey!!</div></div><div class="chatflow-embed" x-type="signature"><br></div><div class="chatflow-status"><img src="https://bolt.im/t/?CFkZMW8778UN98W4t6imYcliQZXm████████████████████tPakZE9jcMgMcuINEmWaUm0XDxYWCGpfK4Ssrw"></div>
Aha! It dials back home to
bolt.im (a domain belonging to Spike). In many cases including this one, this image is non-visible (transparent, 1 pixel size, etc). In the case of Spike, they went with 1×66 transparent pixels.
On the next page, I’ll discuss whether this intrudes on an individual’s privacy, and how to put a stop to this.