I'm creating some HTML emails with images included. For each email the size of the images + email is less than 150kb.
I'm trying to make them work well for the main clients mentioned here http://www.campaignmonitor.com/resources/will-it-work/email-clients/
As far as I can tell there are two main ways of including images with the email:
Embedding the images directly.
Pros: Images load as soon as email is opened (in most clients).
Cons: Does not seem to work well on mobile browsers.
Hosting them yourself and just using links to them in the email
Pros: Seems to have better compatibility.
Cons: Receiver always has to click 'Display all images' button/link, added complexity of maintaining the images on a server.
It seems to me that embedding the images would be the best solution, as it means users will see them straight away after opening the email. Is this correct or would you suggest another way?
Thank you very much for your help :-)
There is no embedding of images where images will auto load. 'Display Images' will always be an option for recipient where there are images.
I assume embedding is to attach the image and then load it into the body, as would happen via pasting an image into Outlook. This method makes larger file sizes in the inbox, and looks messy with all the images as attachments.
By linking to a hosted image, whether you host it yourself or automatically with the Email Service Provider (Campaign Monitor or Mailchimp for example) you don't need to worry about that. That is the industry standard way of sending commercial emails.
Go with an ESP and let them host your images.
Related
I have a habit of sending html emails to my friends. I usually rely on encryption provided by my protonmail account but occasionally I use less secure accounts as gmail and yahoo.
Would sending the body of the message in the form of an image increase my privacy and resistance to being surveiled? I'm mainly concerned with my email and phone number being scraped from the body of the message. When such a measure applied, would using different type of images, let's say jpeg instead of png, make a difference in their resistance to optical character recognition technology?
P.S. I write my emails in LaTeX, compile them to pdf files, and then I use the following code to create my images:
#!/usr/bin/bash
for f in *.pdf; do
pdftoppm -png -rx 1920 -ry 1080 ./"$f" ./"${f%.pdf}"
done
I think I'd class this as inappropriately paranoid.
Protonmail is great, no problem there. No matter what you do, when you send an email to a gmail account, they unavoidably know your email address, and from that they can index into their monstrous data reserves and link it up with not only your phone number, but pretty much everything about you, regardless of what you do within your email messages.
Technically speaking, for clean text on a plain background, PNG will look better, OCR better, and probably compress better than JPEG, but if you're out to hide stuff, overcompressed jpeg will make quite a mess and be harder to OCR, but also harder to read. However, considering that most text-based CAPTCHAs are now fairly easily defeated, nothing you do like this is likely to present any significant obstacle for the likes of google to read if they really want to.
The one thing you can of course do is to encrypt your messages with PGP or S/MIME. This will work fine in gmail; recipients won't be able to read messages in the web interface, but they will have no problem using an external encryption-capable email client (e.g. Thunderbird, Apple Mail, Outlook). Gmail will still of course see all the metadata relating to such messages, so if you're really that concerned, take the OPSEC route and simply don't ever send email to gmail (or gmail-hosted) addresses, or never include your phone number in messages (though that's probably not much of a defence anyway).
I'm trying to send a monthly snapshot of our user's activity using mandrill templates.
I want to be able to send an inline image of a graph of their activity. The image is generated on the server side and attached to the email. I can easily do this when I send to a single recipient by adding the attachment to the images property of the message object.
However, what about when I want to send a batch of emails? How can I ensure that each inline picture goes to each recipient but not to all? I've experimented with using ids in the inline markup
<img src="cid:image_*|recipientid|*">
but although this appears to work, if you open the message source, you'll see that all recipients receive all images - when I want to send a batch to 100's of people at a time, I can't see this as being very effective.
Also have tried
<img src="*|base64string|*">
Which works, however support for inline base64 images in email clients is extremely poor, so it isn't really an option.
Any help would be very appreciated.
If anyone could also tell me what kind of performance tradeoff I'm likely to get by calling the mandrillapi lots of times versus once, that would be good as I'm starting to think this may be the only way to get what I need, perhaps even dividing into batches of 10 at a time and allowing people to download the extra 9 images they don't need (I'm expecting image sizes of 10KB).
Thanks
As of July 2015, this is not possible
Aside from the visual splendor of HTML emails - links are the only thing keeping me from sending plain text emails. They are much simpler for users at times and reduce bandwidth by over 50%. However, forcing my users to copy/paste or (* shiver *) type the URL from the plain text email is not acceptable.
However, it seems like many services such as gmail and hotmail are converting URLs into HTML links. If that's true, then for some lighter emails I could finally switch to plain text (in certain cases) without bothering anyone.
Anyone know what percentage (or what systems or clients) convert text URLs into clickable links?
Some users access via the web (Hotmail/Yahoo/Gmail) while others use clients (Outlook/Thunderbird).
All email progams I know make links clickable, web-based and normal ones.
You should consider putting the links at the end of the mail, and use "[number]" to refer to them:
You should really visit PEAR[1] and friends, PHP[2]!
[1] http://pear.php.net/
[2] http://www.php.net/
That frees you from problems with longer URLs within the text, and it keeps the text readable.
You must not forget one simple fact and that is every mail client make this configurable. So I for one have the option of reading / sending html emails but I don't do that. So it's totally irrelevant how many mail clients support this, the relevant question is how many users have this enabled.
Most services offered online today that claim to "track" e-mails, do so by embedding images in the emails. My questions are:
Is this the only way to do it and if not, what are the other methods?
Are any of the methods actually fool-proof?
Has anybody had any luck with specific software or even an online group?
Yes, this is pretty much the only way to do it. Consider that an email is something that is inherently static. The only way to know if someone has "opened" an email is for the email to send some information back to your server. Most email clients these days support HTML emails, which means that you can get the client to request an image (or anything else) from your server by embedding the proper HTML tags. Other than this, you cannot force an email client to do anything it doesn't want to do. It's a separate program on a remote computer, and you have no control over it.
No, there's no foolproof way. There will always be emails you can't track. If someone downloads their email and disconnects from the internet before reading it, you can't track that email. Most email clients allow you to disable image loading now as well if you want to, so that can block tracking too.
I've usually written my own, so I wouldn't know what to recommend. I imagine most services will be quite similar, so I'd base a product/purchase decision on how easy their front-end is to use.
In addition to pixel tracking, a second way to track open rates is by looking for clickthroughs. If someone clicked through, then they must have opened it. This is infrequent, but it's important not to throw this data away.
More details:
How MailChimp tracks open rates
How CampaignMonitor tracks open rates
Wikipedia on email open rates
Hubspot on open rate issues
Facebook uses a bgsound element in addition to an img element like this:
<img src="http://www.facebook.com/email_open_log_pic.php?mid=999999999999"
style="border:0;width:1px;height:1px;" />
<bgsound src="http://www.facebook.com/email_open_log_pic.php?mid=99999999999&s=a"
volume="-10000" />
This is the best way, and it's hardly ideal - many e-mail clients block images to start with.
No, no methods are foolproof. A foolproof method of detecting if someone had read an e-mail would be a significant privacy issue.
I've used ExactTarget and CampaignMonitor's tracking systems. Both worked pretty well for tracking trends - i.e. twice as many people opened e-mail #1 than #2 - but you never know how many missed opens there are due to images not being shown.
Pixel tracking is the only way to track open rates. Then the links in your emails are also tracked through a redirect service for click rates. Absolutely nothing is going to be foolproof. You will have to use some guess work to figure out your actual open rate since some email clients will only take the text version and not the html and also some clients do not load images by default.
SilverPop is a popular one. They actually use PowerMTA on the back-end. Our company just ended up licensing PowerMTA and writing our own front-end and tracking.
No it's not the only way. Your HTML e-mail can refer to a web server for 'some content' which is then tracked. That could be an image, a stylesheet, some Javascript, etc. Most mail clients hate it and nothing automated is guaranteed to work.
Gain the trust of your recipient and invite them to your website. Track clicks.
It turns out to be quite easy to send emails with .NET that use embedded images. By embedding I mean actually include the image as an MIME attachment.
I'm just trying to figure out whether or not I should embed images as resources for mass mailings (to opt-in / existing customers). Alternatively I would just reference images with a <img src>
Reasons for embedding images
Spam filters may be less likely to block emails - because no tracking pixels exist
Email clients may be more likely to show the images - because no tracking pixels exist
Available for offline viewing
We don't need to host the images indefinitely
Reasons for not embedding images (IMG src attribute pointing to an external site)
Spam filters may be more likely to block large files if we have lots of images
We get to host the images and change them if we made a mistake
We can track views of emails in server logs
Blasting out a tonne of emails should take a lot less time
We take less of a server bandwidth hit for the hosted images555
Sending out many emails with embedded images may take a long time becuse we have to send 400kb for each email
I'm sure there are more reasons.
I'm most concerned about spam related issues. Curious for anybody's input
You can at least check the spam-score of the email you've created. Checking two versions with and without embedded images. A lot of mailing applications (mass-mailers) offer some sort of spam check functionality. Or you could use a tool like: http://spamcheck.postmarkapp.com/
Try base64 embedding?
http://yellowgreen.de/image-to-base64-string-encoder