What the latest figures are on people viewing their emails in text only mode vs. HTML?
Wikipedia and it's source both seem to reference this research from 2006 which is an eternity ago in internet terms.
An issue with combining both HTML and text based emails is taking a disproportionate amount of time to resolve given the likely number of users it is affecting.
As with web browser usage statistics, it depends entirely on the audience.
I have access to a bit of data on this subject and it seems that text-only email use is very low (for non-technical audiences, at least). <0.1% up to ~6% depending on demographic.
It's not that much effort to do both (especially if you can find something to help you do the heavy lifting when creating multipart MIME containers), and you can always write a script to generate text from your HTML or something.
Related
It's been years since I haven't seen, or heard of, any email client which wouldn't be capable of reading, and displaying, HTML.
I'm in the process of creating email templates for a new website, and wondering if it's worth the effort to try to provide a text version of every automated email sent.
To put things simply, is there still any good reason to send a text version along with HTML emails?
A text version will definitely reduce the likelihood of your message ending up in spam, and will be friendlier to user agents that can't or won't display HTML. A text version can be generated automatically from the HTML by most email libraries.
Why purposefully alienate some users when the alternative doesn't cost any more work?
I think it depends if this option is available in your subscribe form. If this isn't the case, there's no reason to spend time or money to create a text version.
I think it is the important part of sending an email campaigns to clients. You need to make sure that you have a text version also in case the rendering client is not able to handle html pieces. This helps to make sure that you are at least not spamming as well. Also almost all of the marketing email engines have a default option to convert the html email into text version if you don't specify the text version.
HTML e-mails are a complex beast. Deciding what to send (as the sender) and what to display (as the recipient) is tricky and potentially dangerous.
On the recipient side of things, we have webmail and we have regular e-mail clients. For my purposes, I consider 'webmail' anything that displays the HTML e-mail as part of something that in itself is HTML, and regular e-mail clients anything that displays the HTML e-mail in a different context (e.g. OS- and program-specific GUI).
What should webmail do with HTML headers (<head>, <title>, <meta>, ...) in an e-mail?
Is there a spec somewhere, be that as an actual standard or de-facto-standard?
My motivation for asking is that we use HTML Purifier to sanitise our HTML and if its Core.CollectErrors feature reports changes, they're reported. This 'reported' is both necessary... and frustrating. We strip out some of the reported errors as insignificant for our purposes, but HTML headers mark a massive hurdle:
Someone could potentially use <link> in their e-mail, which we would strip out. (HTML Purifier is intended for HTML fragments, not full documents)
The desire to use things like <link> in HTML e-mails certainly seems to exist, and there are plenty of e-mail clients that send <meta>-tags in an HTML header (e.g. Outlook), but how are things handled in the wild? Is it safe to strip them out silently (which for our purposes denotes a 'non-breaking change') and lay proverbial blame on the sending party if it does break? Is that reasonable? Has someone ever decided this in the one or other way? My google-fu is weak. :(
I seriously doubt there is a spec anywhere which specifies how HTML emails should be embedded into webmail clients. It's mostly a question of achieving parity with existing webmail providers which provide the ability to view HTML email. I suspect stylesheets are a notable exception, but I also suspect most HTML mailers that support that heavy styling are fairly constrained in what they can and cannot do, given how webmail things may handle them. I'd suggest doing some experiments, and consulting the source code of open-source webmail systems like SquirrelMail.
If you are worried about information loss, one thing that many clients allow you to do is download the original HTML, for offline viewing. Of course, it tends to be pretty atrocious, so I don't know why anyone would do that.
You should look at:
http://htmlemailboilerplate.com/
You will find a boilerplate code for HTML emails. There is also a good practice slideshow.
My approach to HTML email is to to write the sort of basic HTML we were doing in the 1990's - table layouts, minimal inline CSS (for colours only) and thats pretty much it. I don't know how modern clients deal with CSS positioning but people are still using Outlook 2003 which I believe is based on the hateful rendering engine that runs IE6 - so it pays to go for lowest common denominator.
I've never seen anything that looked like a standard for it, i've seen some email clients (GMail) strip out various things - including CSS, and others just ignore certain things (Outlook & background images).
Rationally, I can't think of what use any meta information would be in an email anyway - its hard enough to get people to read your mail anyway, I suspect even less will view the source! I've always included a title tag in case anything wants to use it as a subject - but even thats a stab in the dark.
Whenever i've looked at how mails are requested server side - admittedly a while ago, but I never noticed that anything was cached. You open the mail, the requests are made again. I'm sure things have moved on since I last checked, but personally - i'd still be inclined keep HTML email as simple and stripped back as possible.
I would like to know if and how it is possible to create a clickable email-link for websites, that are "encrypted" in a way emailspiders can't collect them and it is still possible for living users to click it to open in email-clients or even copy it.
I saw some links that were done in javascript but I on't know how they did this and how "safe" they are.
thank you in advance for any reply
Most approaches to this are splitting the address across multiple elements and inserting extra formatting; then for JS-enabled browsers, they use JavaScript to turn it back into an e-mail address.
The poster example for this is SpamSpan, which even has several "levels" of obfuscation - each level progressively less and less resembles an e-mail in the source code, yet it still manages to piece it back together by JS. Although some spambots today are supposedly capable of executing JavaScript, te vast majority doesn't - and the e-mails are still human-readable with JS off. An advantage of JS-assisted de/obfuscation is that it doesn't rely on external servers, you just need to (simply) integrate the JS library.
Another approach is taken by reCAPTCHA Mailhide - the e-mail is revealed only after solving a CAPTCHA (same type as for normal reCAPTCHA). This is less convenient for the user, but practically safe against robots. A disadvantage of this is that it depends on reCAPTCHA's servers (in essence, on Google) - some people are dead-set against any external dependencies.
This would be a very simple and effective way:
Scramble email addresses
All it does is convert it into ASCII, and all you need to do is insert it where your email address would go!
Although there are more (crazily) secure ways you can choose, this would be the simply option. You can also try this solution, it uses JavaScript to protect your email.
Hope this helps!
Our site generates several emails per day, a lot of which can contain awkward links, such as http://company/process/task?id=1234-4123-2352-1234&user=xyz...
Consequently I have been sending text only emails, on the suspicion that they will be treated more 'fairly' by email filters along the way. I cannot afford to lose emails to clients.
Lately I have been wanting to add more content to the outbound email. This is causing problems, as text-only emails start looking really ugly, really quickly when content builds up.
My question is simple... Do I face any risk moving to HTML based emails, especially if I generate awkward links that are then 'hidden' under cleaner looking href links?
You should use multipart/alternative emails to send HTML and Text in the same email. In order to make sure you get treated fairly by SPAM filters, make sure the text content of the two formats is nearly identical.
Some links to get you started
http://en.wikipedia.org/wiki/MIME
https://www.rfc-editor.org/rfc/rfc2046#section-5.1.4
If you have any questions about this feel free to comment on this answer and I will give more detailed answers as soon as time allows
Yes, I realize this question was asked and answered, but I have specific questions about this that I feel were not clear on that thread and I'd prefer not to get lost in the shuffle on another thread as well.
Previous threads said that rendering the email address to an image the way Facebook does is overkill and unprofessional user experience for business/professional websites. And it seems that the general consensus is to use a JavaScript document.write solution using html entities or some other method that breaks up and/or makes the string unreadable by a simple bot. The application I'm building doesn't even need the "mailto:" functionality, I just need to display the email address. Also, this is a business web application, so it needs to look/act as professional as possible. Here are my questions:
If I go the document.write route and pass the html entity version of each character, are there no web crawlers sophisticated enough to execute the javascript and pull the rendered text anyway? Or is this considered best practice and completely (or almost completely) spammer proof?
What's so unprofessional about the image solution? If Facebook is one of the highest trafficked applications in the world and not at all run by amateurs, why is their method completely dismissed in the other thread about this subject?
If your answer (as in the other thread) is to not bother myself with this issue and let the users' spam filters do all the work, please explain why you feel this way. We are displaying our users' email addresses that they have given us, and I feel responsible to protect them as much as I can. If you feel this is unnecessary, please explain why.
Thanks.
It is not spammer proof. If someone looks at the code for your site and determines the pattern that you are using for your email addresses, then specific code can be written to try and decipher that.
I don't know that I would say it is unprofessional, but it prevents copy-and-paste functionality, which is quite a big deal. With images, you simply don't get that functionality. What if you want to copy a relatively complex email address to your address book in Outlook? You have to resort to typing it out which is prone to error.
Moving the responsibility to the users spam filters is really a poor response. While I believe that users should be diligent in guarding against spam, that doesn't absolve the person publishing the address from responsibility.
To that end, trying to do this in an absolutely secure manner is nearly impossible. The only way to do that is to have a shared secret which the code uses to decipher the encoded email address. The problem with this is that because the javascript is interpreted on the client side, there isn't anything that you can keep a secret from scrapers.
Encoders for email addresses nowadays generally work because most email bot harvesters aren't going to concern themselves with coding specifically for every site. They are going to try and have a minimal algorithm which will get maximum results (the payoff isn't worth it otherwise). Because of this, simple encoders will defeat most bots. But if someone REALLY wants to get at the emails on your site, then they can and probably easily as well, since the code that writes the addresses is publically available.
Taking all this into consideration, it makes sense that Facebook went the image route. Because they can alter the image to make OCR all but impossible, they can virtually guarantee that email addresses won't be harvested. Given that they are probably one of the largest email address repositories in the world, it could be argued that they carry a heavier burden than any of us, and while inconvenient, are forced down that route to ensure security and privacy for their vast user base.
Quite a few reasons Javascript is a good solution for now (that may change as the landscape evolves).
Javascript obfuscation is a better mouse trap for now
You just need to outrun the others. As long as there are low hanging fruit, spammers will go for those. So unless everyone starts moving to javascript, you're okay for now at least
most spammers use http based scripts which GET and parse using regex. using a javascript engine to parse is certainly possible but will slow things down
Regarding the facebook solution, I don't consider it unprofessional but I can clearly see why purists may disagree.
It breaks accessibility standards (cannot be parsed by browsers, voice readers or be clicked.
It breaks semantic construct (it's an image, not a mailto link anymore)
It breaks the presentational layer. If you increase browser default font size or use high contrast custom CSS, it won't apply to the email.
Here is a nice blog post comparing a few methods, with benchmarks.
http://techblog.tilllate.com/2008/07/20/ten-methods-to-obfuscate-e-mail-addresses-compared/