The Technical Realities of Email Privacy
Back to Privacy Guides
The Technical Realities of Email Privacy
Basic<br>Solène Rapenne
Introduction
Email, the ubiquitous communication tool, was not originally designed with modern privacy concerns in mind. Its underlying architecture contains limitations that could expose sensitive information to potential exploitation.
This technical guide will examine the core issues threatening email privacy. We’ll dive into the risks posed by email headers, which can reveal details about participants and content. Additionally, we’ll explore the security challenges associated with MIME-encoded content like HTML, and the limitations of encryption at different levels.
By reading this guide, you will gain the knowledge required to comprehend the privacy risks inherent of email design.
Email structure: A technical overview
An email is composed of two parts: the body and the headers.
The email body is its content: it’s what you write within the mail and attached files, if any. Email body had to adapt to progress in types of content added beyond regular text, for example file attachments and formatted texts. Email clients were improved to recognise different parts of the email to be able to render it, whether they are text, HTML or binary files. Emails are now using MIME encoding to distinguish each chunks of the body payload from each other.
The other part of an email is called header, which is the metadata associated to the body, where each piece of software involved in the email delivery may add information.
It is possible to look at the emails headers in most email clients, this is often hidden under a feature called “view source” or “display headers”. Enabling it will let you see the raw email where the headers are always at the beginning of the email.
A simple email would look like this:
Return-Path:<br>Received: from localhost<br>by mail.domain.example with LMTP<br>id xNQbIp9GhWYroAAA23Ik0Q<br>(envelope-from )<br>for ; Wed, 03 Jul 2024 14:39:59 +0200<br>Delivered-To: user@mail.domain.example<br>Received: from localhost (mail.domain.example [local])<br>by mail.domain.example (OpenSMTPD) with ESMTPA id bdd779f0<br>for ;<br>Wed, 3 Jul 2024 14:39:59 +0200 (CEST)<br>From: Pick a name<br>Date: Wed, 3 Jul 2024 14:39:59 +0200 (CEST)<br>To: user@mail.domain.example<br>Subject: email subject here<br>Message-ID:
The content always starts after a blank line to separate it from the headers.
User
Let’s dissect the above email, field by field:
From: name and email address of the sender
To: names and email addresses of recipients
Date: date of the email, it is set by the sender and can be entirely crafted, emails client could be configured to display either the date of reception or the email date
Message-ID: unique ID of the email, it contains the mail server hostname, it is used to group emails in threads
Subject: the subject that appears in your email client, it can be empty
Return-Path: indicates the email address to use when replying, it can be different from From
Delivered-To: address or user name of your account, it could be different from the address in From if you use an email alias
Received: technical information about email delivery, each SMTP server involved in the delivery add a Received header
Potential privacy issues related to emails
Regardless of whether you are reading human-written or machine-generated emails, or composing your own, there is private information shared in them.
Sending emails
When sending an email, any reasonably featured email client will add the following fields: Date, From, Subject, To (and CC/BCC, if any)
However, some email client adds extra headers to the email, although it is not required by the protocol. They can add information such as your email client and/or your operating system version, your SMTP username and your system hostname. This can tell a lot about you and can be used to profile you.
Once the email is transmitted to your SMTP server, some of these headers can be relayed in case of a misconfigured SMTP server, worse, the server can also add information such as your SMTP username and public IP address.
The public IP address could provide your approximate geolocation to your recipient, though the accuracy would be limited in most cases. However, if you are using a VPN, the recipient will not know about your real geolocation, but will be able to determine that you are connected to a VPN gateway, and potentially the VPN provider you use.
A properly configured SMTP server should not share any personal information. Additionally, some email providers offer the option to strip unnecessary headers, further enhancing your privacy.
As an email gets routed through SMTP servers for delivery, each of them will add information about the previous relay. This is a standard part of the email delivery process and does not create a privacy risk. The added information does not contain sensitive details that could compromise...