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.
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.