Are you sure Mutt's not doing this?

I read my mail with Emacs, but according to https://emailprivacytester.com/ , when I click on a message, Emacs parses the HTML and inserts images into the buffer. This is default behavior with the `notmuch` mail reader

EDIT: Chat with dkg on the #notmuch IRC channel shows there's a patch to fix this that isn't in a release quite yet.

My point: Be careful, even if you're using a "dumb" mail client! :)

A typical Mutt configuration relies on the entry for text/html in ~/.mailcap. It's quite common to use lynx for rendering, as in the following:

    text/html; lynx -dump %s; nametemplate=%s.html; copiousoutput

Since lynx doesn't load images, that would be safe from this kind of tracking. But another configuration using a different renderer might allow it.

Furthermore, it is also possible to prefer the plaintext version of an email if there's a choice. From my ~/.muttrc:

    alternative_order text/plain text text/html

I can't remember ever being put out by not being able to read messages that fetch images from the web. Even if I have to open a URL, I do it in Firefox, where I run RequestPolicy.

Are you sure lynx doesn't fetch any external resources? Some text-mode browsers (I forget if elinks or w3m does this) fetches external CSS by default so they can attempt to render fonts on the the 16-color terminal. :)

The "right" way of doing this (calling lynx in a network-restricted cgroup/chroot/container) sounds like a pain.

Lynx doesn't support images, CSS or script. It does support cookies and redirects (by default it prompts for both). Basically, it renders the bare HTML of the page you open, without fetching external resources. If you find it behaves differently, make sure your lynx command isn't actually symlinked to links (or another text browser with graphical/enhanced capabilities).

I'm sure. Mutt gives me direct control over how it processes MIME attachments with particular content types. I'm using this to make sure that text/html only gets parsed by a confined converter. See my link for details.

Just gonna hijack this thread to mention that if you use Gnus (the other Emacs mail client) to read your email you can use the variable "gnus-blocked-images" to block any images that match a URL.

Doing

    (setq gnus-blocked-images ".*")

will block all the images in the emails.

I tested it using "https://emailprivacytester.com" and the it picked up only the DNS prefetch link/anchor which I assume are due to my ISP and not Gnus.

Gmail isn't doing this by default but Inbox does it -- that's was prevented me from switching.

I guess they "new take on mail" by google is not designed for end-users privacy.

Google actually uses an image proxy to thwart tracking based on images.[1]

http://googlesystem.blogspot.ca/2013/12/google-uses-proxy-to...

Which won't work if it's a unique image (since it won't be in the proxy). And if it is a tracking image, it'll probably be unique.

If it's a unique image, then presumably Google reads it and pre-caches the image on receipt. So all you'll get from 1 pixel image is confirmation of email delivery, which is something you get with SMTP anyway.

Of course if Google wait to cache the image when you actually read it, then this isn't true. But I'm prepared to give them more credit than that.

> So all you'll get from 1 pixel image is confirmation of email delivery, which is something you get with SMTP anyway.

You'll get a read-receipt, which SMTP doesn't offer.

AFAIK they do this for all images. Not just commonly embedded images.

Except it doesn't thwart tracking the actual open. Just the IP of the end user, etc: http://techcrunch.com/2013/12/12/gmail-open-rates/