If it’s prefetched, it doesn’t matter that you reveal that it’s been “opened,” as that doesn’t reveal anything about the recipient’s behavior, other than that the email was processed by the email server.
Personally speaking, I’ve never been a fan of this method because to the hosting web server it was still fetched. That might confirm that an email address exists or (mistakenly) confirm that the user did in fact follow the link (or load the resource).
I have ad and tracking blocked like crazy (using DNS) so I can’t follow most links in emails anyway. External assets aren’t loaded either, but this method basically circumvents that (which I hate).
This is why every single email client for the past 2+ decades blocks external images? This didn’t occur to the AI geniuses?
IME they usually proxy and/or prefetch images for caching instead of blocking them. Only spam content is blocked by default.
This wouldn’t help, would it? How would you prefetch and cache:
site.com/base64u-to-niceware-word-array/image.gif
? It would look like a normal image URL in any article, but actually represent data.
Note: “niceware” is a way to convert binary or text data into a set of words like “cow-heart-running-something-etc”.
If it’s prefetched, it doesn’t matter that you reveal that it’s been “opened,” as that doesn’t reveal anything about the recipient’s behavior, other than that the email was processed by the email server.
Personally speaking, I’ve never been a fan of this method because to the hosting web server it was still fetched. That might confirm that an email address exists or (mistakenly) confirm that the user did in fact follow the link (or load the resource).
I have ad and tracking blocked like crazy (using DNS) so I can’t follow most links in emails anyway. External assets aren’t loaded either, but this method basically circumvents that (which I hate).
an email for a receiver that doesn’t exist, more often than not, goes back to the sender after e.g. 72h. That’s by design.