I love this! At a few previous workplaces I could have put this project to good use in our mail delivery system. But it is still a testament to the huge difference between doing something and doing something right.
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.
Email deliverability these days is heavily based on sending IP reputation, to a lesser extent domain reputation, and finally content.
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.
If you send a plaintext email that is more than just a link to a dodgy domain you are guaranteed to get through (unless you're already on a blacklist). This is the only kind of spam I still get. Even spammers know to use plaintext (well, some)!
Well, yes, mostly. But you also want your email to be read, not only delivered. Your email mail also contain some kind of CTA (call-to-action, website to visit and so on...) which you are trying to get the reader to respond to. Those numbers may be higher with well designed "beautiful" html mails than plain text ones.
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.
Thank god. Crafting HTML email is a thankless job IMO, and Googling for tips/help/pointers/bugfixes always makes me feel like Wall-E trying to sort through mountains of marketing spam for some actual technical help.
Nah, if someone sends me HTML it gets parsed into plaintext and if it doesn't work I don't care what's in it. You want to send me a pretty document - feel free to send me an attachment or a link. HTML emails are always ridden with superfluous disclaimers and signatures not using the -- convention, they're a waste of time.
I sympathize, but I'd much rather somebody send me an HTML email than an attached Word document, which is the next likely candidate in most workplaces.
There are valid uses. My hybrid photo-sharing/blogging service lets you send an email update with thumbnails inline, so you can tell family/friends about your latest doings without making them click a link out. http://ourdoings.com/
I suppose you could generalize this by saying HTML email is useful when you have images that are informational, not just decorative.
at the least you can be sending multipart/alternative to include both a text/plain and html body, so you don't have the horrible situation of people getting html source dumped at them. Most webmail clients these days support 'rich content' to a reasonable degree, but a lot of people still have old desktop clients that'll just give up and throw it all at them.
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.
Sending HTML-only email is still a large spam flag, even at major ISPs, independent of the concerns about client compatibility.
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.
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.