3 ms·

Here's an question... Suppose I'd like to send emails that include images. The images are content, I don't care about tracking. Is there any way to do that in a

by dynm 5y ago

Here's an question... Suppose I'd like to send emails that include images. The images are content, I don't care about tracking. Is there any way to do that in a way that's privacy friendly? The natural way of doing this would be embedded images. However, it seems that many mail clients don't support these. (https://www.emaillistvalidation.com/blog/embedded-image-support-in-html-email/ https://www.emaillistvalidation.com/blog/embedded-image-supp...) Are there any other options? The only other option I can see would be to use SVG images and then sort of "compile" the SVG into the html source. However, given how email clients have limited html support, this doesn't seem workable either... It's frustrating that these tracking pixels have made genuine content images so unreliable.

colechristensen 5y ago
Gmail proxies images, if you send everybody the same image you will get very little information about who is grabbing the image and when (i.e. you'll be able to tell when google (re)populates the cache which gives some small indication that your email is being opened).
- dynm 5y ago
  This indeed prevents me from tracking. I should have been more clear that my "real" goal is that privacy-sensitive readers will be able to see images. I think these people won't know that the image isn't unique, and so won't load the images.
kayodelycaon 5y ago
The email validation page is incorrect (possible due to being out of date). Apple Mail on iPhone can render embedded images just like Safari can. I use them in a few personal projects.
legitster 5y ago
Tracking pixels and tracking links only work because there are unique identifiers in the URL. So if you just reference the image's direct link in the HTML of the email there's really no information to be gleaned outside of the normal email server handshake. However, when Google proxies the image in an email, there is no way for the user to know the original URL and see if it has a unique identifier or not.
- seedless-sensat 5y ago
  If you "View Original", the HTML contains the original URL
crispyporkbites 5y ago
If it's just one or a handful of emails, or a small image, attach the image and use it's Content ID to refer to it in the HTML of the email: <img src="cid:some-image-cid" alt="img" /> pretty much all email clients support it
- dynm 5y ago
  Thanks! Do you think this might increase the odds of the email going to spam? (This might be why you mentioned not having too many images.)
chrismorgan 5y ago
That article doesn’t impress me. Their remarks about CID image embedding are fairly incoherent and suggest they have largely just copied stuff from https://www.campaignmonitor.com/blog/email-marketing/embedded-images-in-html-email/ https://www.campaignmonitor.com/blog/email-marketing/embedde... and added a few bits of their own to avoid being dinged by Google for plagiarism, but didn’t really understand what they were adding. > The impairment of this process upturns the email size while attaching an image that affects deliverability. Well this is some nice word soup. I think that by the “impairment of this process” they mean “crafting the MIME message so the cid: URLs are all right”, which honestly isn’t that complex, and libraries tend to help you with it. For the rest of the sentence, I think what they’re trying to say is “using attachments for images makes the email bigger and may cause it to be rejected”. That’s… not a particularly reasonable claim. Also they don’t point out similar on inline data: URI images, which is poor of them. The fact of the matter is that the cid: and data: approaches will both use base64 or similar encoding. > The CID email embedding method is not well applicable for browser-based email. This is somewhere between mostly and entirely false. If they mean webmail can’t read and display the <img src=cid:…> approach, they’re flat-out 100% wrong. It’s completely robust, supported absolutely everywhere that supports HTML markup. If they mean webmail can’t author the <img src=cid:…> approach, well, that’s a bit more of a mixed bag. Some can, some can’t—and in some cases it depends on how you add the image (via an “insert image” toolbar button, via {dragging and dropping/copying and pasting} {an image/a remote image reference/some rich text including an image/some rich text including a remote image}, and several more—there are many ways, and some clients don’t intercept them all). No, the real problem of the CID approach is that the image is an attachment, and although the client will almost certainly respect the `Content-Disposition: inline` header on the attachment and/or observe the fact that it’s used in the markup, and not show it in the list of attachments (or show it separately in some way), for mailbox search purposes it’ll almost certainly be included, and so queries like `has:attachment` will match the email. This makes the tempting idea of using this to put an image in your signature extremely problematic, because now it’ll be impossible to search for emails where you attached something, because every email has an attachment.

by dynm 5y ago

colechristensen 5y ago

Gmail proxies images, if you send everybody the same image you will get very little information about who is grabbing the image and when (i.e. you'll be able to tell when google (re)populates the cache which gives some small indication that your email is being opened).

dynm 5y ago
This indeed prevents me from tracking. I should have been more clear that my "real" goal is that privacy-sensitive readers will be able to see images. I think these people won't know that the image isn't unique, and so won't load the images.

kayodelycaon 5y ago

The email validation page is incorrect (possible due to being out of date). Apple Mail on iPhone can render embedded images just like Safari can. I use them in a few personal projects.

legitster 5y ago

Tracking pixels and tracking links only work because there are unique identifiers in the URL. So if you just reference the image's direct link in the HTML of the email there's really no information to be gleaned outside of the normal email server handshake. However, when Google proxies the image in an email, there is no way for the user to know the original URL and see if it has a unique identifier or not.

seedless-sensat 5y ago
If you "View Original", the HTML contains the original URL

crispyporkbites 5y ago

If it's just one or a handful of emails, or a small image, attach the image and use it's Content ID to refer to it in the HTML of the email: <img src="cid:some-image-cid" alt="img" /> pretty much all email clients support it

dynm 5y ago
Thanks! Do you think this might increase the odds of the email going to spam? (This might be why you mentioned not having too many images.)

chrismorgan 5y ago

That article doesn’t impress me. Their remarks about CID image embedding are fairly incoherent and suggest they have largely just copied stuff from https://www.campaignmonitor.com/blog/email-marketing/embedded-images-in-html-email/ https://www.campaignmonitor.com/blog/email-marketing/embedde... and added a few bits of their own to avoid being dinged by Google for plagiarism, but didn’t really understand what they were adding. > The impairment of this process upturns the email size while attaching an image that affects deliverability. Well this is some nice word soup. I think that by the “impairment of this process” they mean “crafting the MIME message so the cid: URLs are all right”, which honestly isn’t that complex, and libraries tend to help you with it. For the rest of the sentence, I think what they’re trying to say is “using attachments for images makes the email bigger and may cause it to be rejected”. That’s… not a particularly reasonable claim. Also they don’t point out similar on inline data: URI images, which is poor of them. The fact of the matter is that the cid: and data: approaches will both use base64 or similar encoding. > The CID email embedding method is not well applicable for browser-based email. This is somewhere between mostly and entirely false. If they mean webmail can’t read and display the <img src=cid:…> approach, they’re flat-out 100% wrong. It’s completely robust, supported absolutely everywhere that supports HTML markup. If they mean webmail can’t author the <img src=cid:…> approach, well, that’s a bit more of a mixed bag. Some can, some can’t—and in some cases it depends on how you add the image (via an “insert image” toolbar button, via {dragging and dropping/copying and pasting} {an image/a remote image reference/some rich text including an image/some rich text including a remote image}, and several more—there are many ways, and some clients don’t intercept them all). No, the real problem of the CID approach is that the image is an attachment, and although the client will almost certainly respect the `Content-Disposition: inline` header on the attachment and/or observe the fact that it’s used in the markup, and not show it in the list of attachments (or show it separately in some way), for mailbox search purposes it’ll almost certainly be included, and so queries like `has:attachment` will match the email. This makes the tempting idea of using this to put an image in your signature extremely problematic, because now it’ll be impossible to search for emails where you attached something, because every email has an attachment.