From 2020:
(With examples of various tracking pixel parameters)
Is it still enough to disable remote content in email clients, or to display messages as text only?
1 Like
I would think disabling HTML ought to be enough.
1 Like
I do both as a matter of course.
2 Likes
My email client is plain text only, so I don’t worry about it.
I guess if I ever start reading mail on a phone, I’ll have to come looking for help.
1 Like
This is what I do. Disabled by default in all emails. Selectively enabled e.g. for specific personal senders.
Another approach is: don’t subscribe to their spam. Problem solved (mostly). If unsubscribing then tell them that it’s because they use tracking pixels.
Not dissing your choices but this will never be my choice.
I see that your link says “Rich text isn’t that great, anyway” but I happen to like being able to format my communication and believe that it adds value that can’t be achieved (as well) with various plain text hack notations. I can see that, most of the time, a meaning can be conveyed in plain text but I really don’t want to go back to the days of plain text.
The bottom line really is that a user makes a trade-off i.e. the value that you put on the formatting v. the value that you put on avoiding privacy (and security) exploits. How that trade-off pans out depends on the individual user.
As an example, your link says “Images can simply be attached to your email” but then you can’t provide more than one image while still providing a convenient caption / description / metadata for each image. In fact there is no privacy issue with inline images anyway. The privacy issue is with remote images.
(Spammers like remote images not just because of the tracking but because it reduces their volume of outbound data if a large proportion of users will not receive the spam or will not read the spam.)
Your link says “How do you speak bold text aloud?” but of course that question applies whether the boldness is conveyed using an HTML tag or the boldness is conveyed using various plain text hack notations. (If the purpose of bold is emphasis then in theory a screenreader can implement that. A human-being reading out the text could do it. So why not the software? And if not then that is a limitation of the software.)
As a quirky historical aside, you will note that HTML has an actual emphasis tag, <em>, as distinct from either <b> (bold) or <i> (italic). However I think many HTML documents will not use these correctly.
Going off into la la land … is what we need a new markup language that
- is designed specifically for email
- is not HTML nor a subset of it
- is rich but not too rich
- doesn’t require a zillion lines of code to implement and a zillion lines of document to specify
- avoids all of the privacy or security damaging functionality in HTML e.g. no scripts, no active content, no remote content?
1 Like
Lately, I’m seeing more commercial senders that either say:
“Your email client does not support HTML messages.
Please click the following URL for the online version.”
Or display nothing at all in the body of the text, just a blank email body, unless I switch from “Plain text” to, for instance, “Simple HTML” in Thunderbird.
It seems they are trying to ensure some kind of tracking happens.
(These emails are from companies I have some sort of minor service with, or some other intentional connection, not from spammers.)
I use Thunderbird the other way i.e. HTML in preference to text (but with restrictions on access to remote images) so take with a grain of salt but I think this is standard behaviour for multipart/alternative (which is quite commonly used) so if I am understanding correctly … you are saying that it is becoming more common for there to be no useful text/plain alternative part. That part is either blank or directing you to the online version.
Warning: If you accept the direction to the online version, you may be getting more tracking than if you just take the HTML alternative part in the first place - because while Thunderbird can easily block remote images, you are directly and unavoidably accessing remote content via the online version (the HTML itself) and it may be impractical to configure your browser to block remote images, not that it matters as much once you have accessed the remote HTML.
So I’m wondering whether it is time for you to change your strategy.
1 Like
I usually switch to “Simple HTML” temporarily to see the content in the problematic email, then switch back to text-only. (Unfortunately, doing so gets applied to every email in Thunderbird, not just the one.)
It would be a rare occurrence if I clicked an email link to open a webpage; typically, if necessary, I would simply open the main site from the browser and then try to find the related content, if I felt the need to see it at all. Hopefully NoScript, uBO, etc., would nullify any tracking for me, except from the allowed scripts.
One thing that has always bothered me about Thunderbird is the persistent message reading pane. Although I don’t use it, it’s still there, veiled, but not inactivated. A simple drag of the window brings the content into view. Unless I’m uninformed, there’s no way to close it completely so that email content is not being displayed, hidden from my view, and yet “opened” anyway.
I’m sure that is the reason for some, but I think many aren’t even aware that plain text exists. There has also been a long going trend to not even send multipart.
I use the plain text mail client mutt. If I am curious about the contents of the HTML part, I might view it as text, but that is getting more problematic because of all the CSS and complex HTML. Lately, I’ve started piping the message through the lynx web browser, which does not access image links except when that link is explicitly selected.
1 Like
True. Sometimes it will be sufficient to extract out the text from the HTML. A challenge with that is pages that use tables for layout purposes, which will then be hard to work with if converting HTML to text.
One thing I’ve noticed a bit of recently is HTML parts that unnecessarily use base64 encoding - so that if you want to eyeball the HTML before allowing it to be accepted, you have to jump through more hoops.
Perhaps you misspelled “pane” and it should be “pain”. 
Can you explain what the problem is? Does F8 not do what you want? I think I see what you mean: F8 minimises the message pane but it is still there. So if, for example, there were a 0-day exploit that could be triggered by processing a message, the exploit might still work even if you have pressed F8.
1 Like
I didn’t know about F8, but in any case, that’s correct: it’s only minimized, so, I’m guessing, potentially exploitable.
Well, needless base 64 encoding of plain text started decades ago, so I guess it was just a matter of time until it started with HTML as well. That has inceased me piping messages through lynx.
1 Like
I guess then you would need to probe the limits of exploitability. So, for example,
- with message display set to HTML (not text)
- and a mail message using
multipart/alternativeto give both HTML and text parts - and loading of remote images enabled
- and the message pane collapsed (minimised)
if you click on a message, does it access the remote image? (The easiest way for you to test this is probably to put the remote image in an unusual domain and detect the DNS lookup of the domain via Pi-Hole assuming that you have enough logging enabled.)
This is by no means a comprehensive test of the potential for compromise by a deliberately malformed message but if the remote image is (attempted to be) accessed then you can pretty much say for sure that Thunderbird processed the mail headers, parsed out the MIME parts, and parsed the HTML - which means that if there are any exploits, they may have been triggered (because that is a lot of processing).
Alternatively, you could look at the source. 
The upside is that that can be one additional bit of information for spam/scam detection in the mail server.
1 Like
PS If Thunderbird actually does access the remote image then that also opens up the potential for compromise with a deliberately malformed image.
1 Like
I imagine the omnipresent preview is only an issue when remote content is enabled (and I don’t know what if any remote content might be activated by merely selecting View Message Body as HTML without then enabling remote content for a sender), but this could still be a problem if, say, one has permanently enabled all remote content for a particular sender, either consciously or accidentally. I’m guessing that tracking scripts would then run even without opening the message, courtesy of the hidden preview pane.
I myself wouldn’t normally enable remote content for any sender. Good idea about using Pi-hole to investigate, but I’m loath to allow any scripts to escape, especially considering commercial senders pepper their mails with scripts from the most Evil corps.
P.S. The preview is active/hidden even in the main mail list, in case anyone is wondering.
Adding to my previous comments, images are not the only remote content in HTML. CSS can be remote. JS can be remote. Either could in theory also be used for tracking.
Yes, I too wondered about how this could be tested safely. It depends on the IT infrastructure that you have available to you.
One option would be to create a second (temporary) Thunderbird profile. The second profile would be specifically for this testing and might contain only one email account, an account the email address for which is not public, created specifically for this testing, and that will never receive email other than what you send to yourself for test purposes. (That should be relatively clean because then effectively while running Thunderbird using the second profile, and not your normal profile, all your existing email accounts and all your existing email is inaccessible.)
Or I guess if you can run a mail server locally, you could pull your entire local network off the internet temporarily.
1 Like
Yes, and I was thinking about certain Evil pixels.
Pi-hole would hopefully catch everything, given the extensive blocklists I have loaded, and the sites I’ve manually blocked. (Plus, I’m now innoculated with @antonis’s Facebook blocking script on my computers, including the L5.
) Still don’t care to test the theory, unless it’s with a temporary account, as you described, and behind a VPN connection, of course.
2 Likes