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
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 have a site with a simple contact form using ASP for customers to e-mail quote requests. However, I'm getting quite a few messages through with no contact information; I think people assume that their e-mail address is coming through automatically.
I'd like a simple way to make the e-mail and/or telephone number fields required, preferably so that the fields are highlighted as such if they're submitted without anything in them. I've Googled for this but they seem either too simple, diverting people to a separate page and requiring a 'back click', or incredibly complicated with massive reams of code.
Any suggestions?
EDITED
You should use a combination of server-side validation as well as client-side (JavaScript) to ensure there are no security holes in your form.
For any specific coding examples, please direct the question to Stack Overflow.
You can use "ASP form generators" that generate both server side and client side scripts.
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!
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.