Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Unfortunately, standardization != widespread use. Tracking pixels are still the most reliable way to know whether a recipient (or many) opened your message.


Unless your recipients use email clients that don't load remote http images except on demand.

I can think of one email client with ~15 million users that does that.


Which client blocks remote images by default? Is it a cli or gui?


Gemail, Outlook.com/hotmail, thunderbird and outlook all block images, unless whitelisted... Now, there may be other providers/clients that don't, but the above accounts for a significant number of users (if not most western mail users).


Gmail does something more interesting. It shows the image by default if the url is not unique, or the image is an attachment. It also uses googles servers to download and cache the image when receiving it.


"When you get a message that has a picture in it, you see the picture automatically. "

https://support.google.com/mail/answer/145919?co=GENIE.Platf...


Gmail automatically downloads and caches images, and loads them from their server instead of from the original remote server, when you read the email.


That only obfuscates the reader's IP. Gmail respects Cache-Control headers, so it will not cache the image if you tell it not to.


Alpine, gui of sorts

K9, gui Android (think it blocks by default, or I turned off auto load when I installed ages ago).


Thunderbird, gui.


I think he meant Gmail




Every mail client I've used, including webmail, has blocked external images by default for at least the last decade.


I believe Exchange/O365/Outlook block by default when the senders are outside the organization.


That's not a good excuse for not implementing a standard. It's also a little like saying "private investigators are still the most reliable way to know whether a person is at home": it's true, but not really a better thing to implement.


Whether a standard has adoption or not is a perfectly good consideration when deciding whether to implement it.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: