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.
Related
for my group at the university I'd like to set up a server-sided email-to-rss service.
It should work like that, that different people can send emails to a certain address (nothing proprietary like gmail but a certain imap or pop server) which will the be translated into an rss feed. One main and important feature has to be that one can see the sender of the email in the feed. Furthermore it would be nice (to take the load off the server) if the emails get translated to a feed only once a day or so.
Does anyone has some input on this subject? Are there any scripts/services which will allow that?
Thanks a bunch.
Instead of "reinventing the wheel", you could use a mailing list that supports RSS. Your people can then write the mails to the mailing list and you can then use the mailing list's RSS feed however you intend to.
This should help you find a solution: https://encrypted.google.com/search?q=mailing%20list%20rss
Pick a programming language you're familiar with, then use either an imap library to fetch the E-mails (through cron, every hour or something like that), or if you have access to procmail on your mail server, launch your script as an email arrives (this shouldn't be too much work to handle for a server, unless you're talking a vast amount of E-mail).
The script would just insert the E-mails into a database, before extracting them and outputting the RSS-feed directly from that (this shouldn't be more than a handful of lines of code).
There's a couple of providers that does this for you, although it seems that the most popular ones have disappeared. Advanced Email2RSS seems to be an option, although I have no idea how good they are or if it'll even solve your issue.
I want my web app to send certain mails as HTML in order to include product images.
I could of course provide a text/plain alternative as well, but is it worth the effort in this day and age? Are there common mail clients that don't support text/html, do many people turn it off for some good reason (I suppose spam, bandwidth), are there other reasons such as decreasing the risk of being classified as spam?
I can theorize, but would be interested to hear if someone has statistics, experience or other insight to support or speak against going text/html only.
You are best to send both because:
It helps reduce your spam score, even more so if your text version has the same text and links as your HTML version. This is especially true on Outlook, where no text version almost guarantees it will go the Junk folder.
A lot of people do request a text version on the client-side. Some old Blackberries default to this setting, and Windows Mobile <= v5.
Provide both. HTML in email has a slew of security problems, so those that are security-minded tend to disable HTML email in favor of plain text. Also, reply quoting conventions are fairly well-establised for text/plain data and not for HTML, making meaningful discussions in pure-HTML mail threads ugly.
Since you do have control over the content of the message, please make the plain text version readable. Some MUAs tend to auto-create the text/plain part, and do a horrible job in doing so. So if your messages are intended for customers, make sure the text/plain part is formatted nicely so you do not alienate them.
I believe clients such as iOS mail use the text/plain version to preview the first couple of lines before the user opens the mail.
I think HTML only is OK, but it should be legible without images downloaded. Outlook and Gmail both block images by default to stop tracking and viruses.
You should always have a text/plain alternative. I don't have statistics, but I'm sure that a lot of people disable HTML emails. Including me, because I'm annoyed by all those product images and meaningless fancy newsletters.
Stats I found were that 90% of emails were viewed in html-capable email viewers. If you choose not to include an option for plain text, you could be losing out on 10% of your audience. On the other hand, a well designed html email could more than outperform the 10% loss, so it might be worth the trade off.
I am struggling to get both working on PHP with Hostgator, so I think I'm going to focus on the low hanging fruit (the 90% who view html emails) and not worry about the 10%. Like IE 7, there comes a point where you can no longer support all platforms.
Google does HTML email by default, this includes Google Apps for Business and Google Apps for Educations. Thus millions of Gmail users send and receive HTML email rather than plain text email. Not sure whether there are any better stats than that out there.
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.
Is it possible to have some kind of mini app running in an email.
When the email arrives the email message should contain static text, but also an interactive component where the user can select attachments, fill out a few fields and hit reply.
Yes, but in limited circumstances. If you are planning for an office intranet all running Open Office/MS Office/Lotus/etc then yes. Otherwise very few mail clients willingly support them across the board. If you don't have control over the client software you should stick to the basics.
To ensure delivery and legibility of the e-mail in all clients I'd send simple message in plain text and HTML format (no external images) with a web URL for user interaction.
I'm sorry, but it's not a good idea at all. It would be classed as a trojan, no?
What if:
client views all emails in plain text
web based email client
platform limitations eg windows app on a linux client
Personally, I'd look at exactly one of your recieved emails and then assign it to my blacklist...
Thankfully no.
But you cold possibly do something like it with html.
Not really, no. It depends too much on the end user email client, and most of them won't handle something like this.
The solution is to send a link to a page that does that.
Formatting wise you can still do a lot of things using HTML and basic CSS.
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