Do all modern email clients (online and desktop apps) support MHTML email content in which images and other resources are embedded in the email?
In addition is this the standard that should be used to get a consistent HTML email message out or is it better to send HTML emails with linked resources.
Note: I am aware of the 7 reasons why HTML e-mail is EVIL but it is essential in this case. Also I have seen the article on css support in HTML emails and know these pitfalls.
Pretty well all of them. MIME multipart is pretty durn common at this point.
Yes, just keep in mind that many clients do not load the images by default to avoid giving away "alive" account details to spammers.
Don't expect JavaScript to work (some users have it and it works), but Outlook/Outlook Express have had a bad history with JavaScript and IIRC have completely blocked it by default in recent versions.
Related
We're creating a web application that sends emails for different purposes. Since we need to embed images and links in some of the messages, HTML is a must.
Most of the email messages can be customized by our users. We provide a web-based editor to do that. Requiring our users to enter always two message variants, one in HTML, one in plain text, is no option, that's just annoying for the users, so our current approach is to specify a plain-text part with something like "please use an HTML-capable mail client".
Is this a valid approach, or do I break certain clients that could still be relevant? I know that this question depends on our user base, but I'd like to get a general suggestion for "most cases" in the year 2015.
If this is not an option, are there any sensible ways to automatically construct a plain-text message out of the HTML message?
IMO it's a valid approach. I can't think of any commonly-used mail clients that are still plain-text only. Can you?
I have a problem. We've designed some beautiful, responsive email templates that work across mobile/tablet using media queries but contain MSO conditionals to work on Outlook. Turns out, the client now claims they can only send through an exchange-based mailing list. Ouch.
Problem:
If I send from Mac OSX's Mail, it retains the media queries and works (they are then stripped in Outlook when opened by receiver, but that's inevitable)
If I send from Outlook, it strips media queries completely and sends without them
From my thinking, the only solutions are:
Distribute through a different email client that supports both viewport media queries such as Mac Mail and allows connection to Exchange (know any? Thunderbird?)
Somehow obtain the mailing list and distribute through MailChimp or similar
Appreciate any advice anyone may have.
Depends on how good you care in code and whether you'll need clients to access your system. You can go with user friendly, feature packed options like Mailchimp or Campaign Monitor.
Much cheaper but less featured (relies heavily on you integrating through their api) is Sendgrid
If you want to stick to free, PHPList might be a good option.
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!