I have a vendor that uses a service, mailtrack.io, which embeds a single white pixel into email messages for tracking purposes.  When the message is opened, unbeknownst to you, your mail client will render the white pixel and then I assume mailtrack.io informs the sender that the message was read.   Pretty simple actually and clever.  But I’m watching outbound traffic and I saw the outbound connection to mailtrack.io.  When I opened the source of the email, I noticed the line calling the hosted pixel which clued me into what was happening.

Prevention is simple -- the pixel is hosted on a web server and in order to connect back, it needs to lookup the url for the web host.  We can use a hosts entry in order to point that url to 127.0.0.1 (localhost) or a DNS entry to block the entire domain.  For DNS, you have to consider that you’re not always using the same DNS servers which is why I think the hosts file works well – assuming you’re reading your mail on the same machine.  You could also block the traffic at the firewall but you’re subject to the same problem as with the DNS solution in that if you move networks, this other firewall is not blocking the requests.

For the hosts file solution, edit your hosts file and just add mailtrack.io next to localhost.

127.0.0.1       localhost mailtrack.io

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

When your mail client attempts to render the image, the lookup will point back to localhost and mailtrack.io will never receive the pingback.  This method should work for any service such as this one which uses a hosted object.