The email boilerplate for sending out nicely formatted messages
github.com
github.com
Uninformed people just don't get how hard it actually is to send mail. Especially if you have a large distribution list and it is important that your mail does not get caught in over-zealous spam filters. Those people you can point to this project to prove that it takes time and effort to do something as seemingly simple as mailing right.
It is the same with i18n. You can't just i18n:ize a site by storing the text translations in the database and showing the right translation based on the browsers Accept-Language header. It becomes a hugely more complex issue when you consider stuff like search engines, date formatting, currency formatting, whether sunday is the start of the week or not and so on.
Lastly, you may want to measure how many people actually opens and reads your mail and when they do it, instead of just letting it languish in your inbox. It's trivial to do by embedding tracking pixels in the html mail, but impossible in plain text ones. Personally, I abhor html mails like the plague, and the people who believe that bold facing or underlining some text somehow makes it easier to decipher some meaning from the text, but they do have a purpose. Mostly for marketing purposes I admit.
Once you have ticked the core boxes of compliance - clean html in your templates, never send just HTML email but use multipart with plaintext, be sure of your MTA's RFC compliance, sign with DKIM/SPF - then reputation now strongly hinges on recipient behaviour at the largest ISPs. Marking an email as Spam is an obvious flag, but additional heuristics such as open rate, clicks, deletes etc. are used to determine your relationship with that recipient, and your reputation over time.
The most common issues these days with content-based filters come from smaller independently run installs - SpamAssassin, ASSP etc. As a legitimate sender you can usually cover inbox delivery to 90% of recipients by building a solid reputation on your IP with the large ISPs. The final 10% will be related to content, linked domains etc. at the smaller services.
A large reason for the growth in email-as-a-service platforms is the reputation component is already taken care of, and you can focus on content and engagement instead of the finicky aspects of core email delivery.
I suppose you could generalize this by saying HTML email is useful when you have images that are informational, not just decorative.
That said, maintaining 2 templates or deciding exactly how to handle the formatting of the text version can be a hassle. I'm curious how others have handled this problem.
At PostageApp our solution to the problem is a templating engine where you can write your HTML/CSS separately and we inline it at run time to ensure client compatibility. We then provide a separate Plaintext tab with an 'import from html' function which does most of the work for you for managing dual formats.
Also, this was previously discussed here: