3 ms·
This may be useful if you're purposely setting up to participate somewhere with anachronistic rules, as it gives a nice list of clients and configuration settin
by scblock 3y ago
This may be useful if you're purposely setting up to participate somewhere with anachronistic rules, as it gives a nice list of clients and configuration settings to get things working.
But for general email communication the ship sailed many years ago and most people expect the ability to embed photos, tables, lists, and text formatting directly into messages so we can better communicate our intent using modern tools, without writing 'source code' to do it, even that as simple as Markdown (which is based on plain text email conventions). I wouldn't expect anything here to gain traction outside of niche communities, and the "why plain text is better" section is unconvincing.
- chrisfinazzo 3y agoCounterpoint: If you have to guarantee delivery, I don't see how you can choose something other than plaintext unless you can make assurances about the environment recipients are using to read the message. Case in point: Last I heard, The College Board still sends critical test information - admission tickets and the like - in plaintext.
- eli 3y agofar more consequential emails are sent with HTML mail
- chrisfinazzo 3y agoBy volume, yes... However, my choice of this example was intentional. You're not looking for a low bounce rate, you want - and need - exactly zero. Questions about standards are moot in a plaintext environment and security concerns are, if not eliminated, greatly minimized if you can't include images or live, clickable URLs. Business do send a metric fuckton of HTML mail, but they generally have the budget to test for and support more types of clients.
- eli 3y agoClient testing is a fair point, but I'm skeptical of the claims that plaintext improves bounce rate and I don't follow how it improves security unless you mean exploits that target the HTML renderer itself.
- chrisfinazzo 3y agoAs it was explained to me, the worry was less about actual exploits and more to do with supporting various HTML features in the respective clients (Think Caniuse, but specifically for email). Back when I was doing some work in this area, the Email Standards Project was trying to get most of the popular clients to update their rendering engines with this goal in mind. So far as I can tell, this work seems to have been inherited by the people behind the Email Markup Consortium.[1] [1]: https://emailmarkup.org https://emailmarkup.org