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/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.
> 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.