Tracking images in emails are uncacheable specifically because they need to be traceable. For a set of users, you'd send out the same email, but use a different image for each:
and so on. How would you propose caching that? You can't simply ignore the GET parameters since many web services use those to distinguish between different files. And anyways you could even get around that by using URLs like
While I do applaud the decision to route all images through Google servers to hide the user's location, I'm disappointed that images are enabled by default.
>While I do applaud the decision to route all images through Google servers to hide the user's location, I'm disappointed that images are enabled by default.
It is a usability feature.
I can attest that my own mother has no idea why the pictures in her emails don't show up. If this keeps her privacy (or at least what shreds of it remain) and makes it easier, then I don't have a problem with it.
Personally, spam is a thing of the past. Between using multiple email addresses that forward to a few main ones, to spam assassin and Gmail's spam filtering, I haven't seen a spam in years. Even if I did, I highly doubt it would get me to open it.
That leaves promotional emails, which, if I'm opening, I already have an interest in and might as well just see the images. It saves me a click. Rare would be the case where I'm interested in an email enough to open it, but not enough to see the images it contains (which often make reading it a more pleasant experience in the case of headers, gradients, and the like).
The point isn't that the image be shown in the browser, it's that it is requested from the email sender's server. That's how email tracking works. If you're still making the request then this approach doesn't work. (Unless I'm missing something?)
