Does Mozilla Thunderbird leak any personally identifying data?
Mozilla Thunderbird has several fingerprints within the RFC 822 content. This includes the User-Agent, Message-ID, and Content-Type headers as well as how it choses to render HTML, and this is not necessarily a complete list.
There isn't much variation between Thunderbird versions, so I'm guessing your OS and actual Thunderbird version are only visible through the User-Agent header.
User-Agent and X-Mailer headers
Here is a sample Thunderbird User-Agent header:
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0
To disable that, follow these steps:
- Go to Preferences → Advanced
- Enter the Config Editor (lower right button, click "I'll be careful, I promise!" if prompted)
- Right-click and create a New 〉String called
general.useragent.override - Leave the string's value blank (hit OK)
This preference is for renaming the User Agent string, but Thunderbird will recognize a blank string as an instruction to not include the header. Do not forge another common user agent here; some anti-spam systems will notice the forgery and flag your mail as spam.
X-Mailer is another header used to reveal the sending software and its version. It is rarely used in conjunction with User-Agent. Thunderbird, for example, doesn't create an X-Mailer while Windows Live Mail does. Live Mail doesn't create a User-Agent header while Thunderbird does.
Received headers
RFC 821 requires every relay that a message passes through to add a Received header. These typically reveal the sending host's self-reported name (HELO/EHLO), its IP address, its reverse DNS (rDNS), the receiving host's SMTP software, ID for that message as it sits in the queue, hostname, and local date. (There's sometimes more information in there too, like authentication notes and original recipients (before alias expansion).)
When an end-user mail client (formally called a "Mail User Agent" or "MUA") connects to its outbound SMTP server, it must participate in this scheme as well. That means a system name needs to be used in the EHLO. Different clients have different ways of selecting this. Thunderbird uses your LAN IP address in brackets, Windows Live Mail includes your system's NetBIOS name (the same name used by Windows File Sharing), and other clients can use other techniques, including rDNS. Mozilla's choice of using the LAN IP is, in my opinion, the least revealing of the available options.
Others
The Message-ID and Content-Type headers each generate "random" seeming unique strings (the message ID value and the MIME boundary string). These strings have certain patterns that can be used to determine the email client even without a User-Agent or X-Mailer header.
Aspects of other headers or even the HTML code may also reveal that you're using Thunderbird, but such techniques are unlikely to reveal your OS or Thunderbird version and they're unlikely to be as diagnostic than your Message-ID and Content-Type headers, which are in turn less diagnostic than X-Mailer or User-Agent strings.
Thunderbird extensions
There are also a few extensions that will provide more information than you may want to reveal. Enigmail (a PGP add-on) is one of these. See this How to Sanitize Thunderbird and Enigmail blog post for instructions. (That post is also where I learned how to suppress the User-Agent header). For my setup, the Enigmail ad and version were already removed (and the correct omission settings were labeled as default), so this may already be fixed by default in Enigmail.
Do note that when you cryptographically sign something, you are rather explicitly (and verifiably) stating who you are (at least by tying your key to the message) in addition to your email address in the From header.
I can't find anything about windows live mail leaking the computer name. But nevertheless, any email client that renders HTML may leak information. Thankfully, most of them (Thunderbird included) are somewhat clever when displaying HTML mail.
Trivial example
The most trivial information that can be leaked is whether a user opened the email or not. On way to do it is to add something that needs to be fetched from a remote location. For example:
<link rel=stylesheet src=http://my-rogue-server.com/samuel.shofterovish.at.gmail.com/style.css />
The server will give the same file for everyone but will log the request. A simple grep reveals all user who has HTML rendering enabled and opened the email. HTML email is obnoxious today. Some mailers do not even bother using a multipart MIME with text and HTML, they just send the HTML, and MUAs need to be able to render that.
Back to the real world
Most email clients actually do not load external stylesheets, so the example above is poor. But then you have <img>. Most clients disallow <img> (yet Thunderbird did allow it by default once upon a time), but then you have <iframe>. And the list goes on. A well crafted email will use several techniques at once.
Then Thunderbird blocked <img> only from emails that were not in your contact list. But emails can be trivially spoofed. If an attacker manages to spoof an email of someone you know the images will show. This has been fixed in Thunderbird 2.0, and since that time all images are blocked by default. Note that in today's Thunderbird "external images" mean any external content.
Thunderbird had its deal of leaks but they have been fixed quickly. Unless you change the default options the mailer is considerably safe (in terms of privacy) to use. There was a time when Thunderbird was vulnerable to iframes, but that has been fixed too.
So yeah, bugs do occur and sometimes some information may be leaked by some yet unknown (to white hats) means, but that is going into complete paranoia. Even after Mozilla declared that it is diminishing its efforts on Thunderbird in 2012, there have not been any serious issues (the lack of new features may have helped). Unless black hats know something very clever and no one is disclosing it for several years (very improbable), Thunderbird is a rather safe choice in terms of privacy.
Other privacy attack vectors
The MUA (mail user agent, what Thunderbird is) sends X-Mailer:. But believeing X-Mailer is just stupid. Just like an HTTP User-Agent:, X-Mailer: can be set to anything you want. For example, I send this from my mutt:
X-Mailer: Starfleet cruiser 1317C5, private mail version 17.3rc2
Now, other headers are added by the MTAs (mail transport agents) on the path from your MUA to the destination mail server (also an MTA). Taking the header from the comment:
Received: from acerPC (unknown [*redacted IP*])
Your acerPC is set by an MTA, not the MUA. MTAs that run on a NAT device often add and extra from with the private IP of the machine on the inside of the NAT (LAN). For example:
Received: from [10.16.16.63] (kinky-kittens.domain.net [public IP])
Yet, if the MTA processing the email on the NAT device know the mapping between the private IPs and the computer names (note that the mapping may be incorrect), the MTA may use that mapping and give the first from part a computer name. That computer name makes up for a domain name withing that LAN.
This is an information disclosure alright, but has nothing to do with Thunderbird or Windows Live Mail. It has to do with how your machine advertises its name to the LAN, this is most often part of the DHCP configuration.
Extra notes
The MTA at the NAT device may simply be a stateful firewall that will provide the info in the header to the next hop. It should be possible to configure the machine name tp private IP mapping in a firewall (or in a real MTA if that is what is running inside the LAN) to give wrong information.
By sending emails from a machine that is not within a LAN (no NAT) the Received: header set by the next hop in the mail path will know its IP and will be able to perform a reverse DNS lookup and produce a similar header.
References/Related:
- serverfault question about
Received:header in emails - sec.SE question about following an email path by using
Received:headers