Implementation-specific email headers aren't new, and many providers have been leveraging them in one way or another -- probably since email itself came to be.

Implementation-specific email headers aren't new, and many providers have been leveraging them in one way or another -- probably since email itself came to be. Outlook is a great example here. It's basically just value-add's for the client. You can still read email in any client, so why would you choose any specific client? I think the onus remains on the content creators, just as it is on the web and elsewhere on the net, that they only use the extended functionality to enhance the content (and not replace it). An example here would be HTML emails -- which, since you said you prefer plain text, I'm sure you hate? But they are common and those that use them know that they need to include a "view on the web" link for clients who don't understand HTML. I do like plain text the best though, as I think that's where email excels, though SMS has some overlap. Ultrafunk Popcorn[1] was my preferred email client for 5+ years, and was an awesome client. Required only a conf file and something silly like 200k of RAM to run. Sadly, development stopped on it awhile back I think, though it probably still works just fine. It's the equivalent of the foobar2000 music player, dead simple and efficient. 1. http://web.archive.org/web/20130116201517/http://ultrafunk.com/popcorn http://web.archive.org/web/20130116201517/http://ultrafunk.c...