That's true, and I wish that emails could just work like everything else on the web. But simply removing Outlook and all its baggage from the equation would be a big, big improvement on the status quo.
IM is one of the last places on the internet not filled with automated crap, advertisers and spam. And to be fair, some of that automated crap I actually want and browse through at a later time but IM explicitly separates real time messages and newsletters.
Email clients are a bit of an oligopoly, so execution would depend on which player(s) are involved. Most of these initiatives would need an "everyone but Outlook" coalition to succeed.
A few thoughts on implementation:
- Multipart MIME is still a big part of HTML mail, so it would make sense to piggypack on that support. Instead of adding a new MIME attachment for Markdown, it would make sense to extend the existing support for text/plain renditions and find some way to signal that it's Markdown. (e.g. text/plain; charset=UTF-8; variant=MarkdownMail)
- For mail clients that aren't Markdown-aware, it would be important to produce an HTML-rendered variant with a reasonable style sheet.
- A Markdown-first mail client would either need to limit formatting to Markdown or soft-block access to non-Markdown formatting. ("Custom text colors will not be visible on some devices and may be lost when replying. Continue?")
- When viewing a Markdown-enabled message, a Markdown-first mail client would render the text/plain variant in its preferred style sheet, not the HTML-rendered variant.
- When replying to a Markdown-enabled message, a Markdown-first mail client would use the text/plain variant as the source of truth for quoted replies, not the HTML-rendered variant.
A few tricky areas:
- Mail clients would need to agree on a Markdown dialect, especially for extensions like tables.
- Markdown isn't very incompatible with quoting. There would need to be a solution for inline quoting.
- For everyone's sanity, it would seem important to agree on a delimiter to separate prior messages and their headers.
- To not be worse than HTML mail, we'd really need a way to signal that a paragraph is part of a mail signature so that it can be rendered in a subtle way. As much as we might wish that mail signatures would just go away, they will continue to be used, and rendering them as standard paragraph text just makes them more distracting.
Theoretically email client vendor can host working group like WHATWG to define standard by picking subset from web HTML/CSS. I don't know why it's not happened.
* iframe content inside message is editable after message sent.
* Java Applet/ActiveX is almost dead, but still available. Should it be allowed on email? (for web mail on IE11/Trident)
* Sanitizing JavaScript from HTML by blacklisting isn't simple operation. Possibly attack vector. (for web mail)
You can already use url() to load background images - seems like this is a solved vector.
> * iframe content inside message is editable after message sent.
Does this really increase the attack surface area, since you can't execute javascript from the iframe?
* Java Applet/ActiveX is almost dead, but still available. Should it be allowed on email? (for web mail on IE11/Trident)
No, because that's not in the HTML/CSS spec and modern browsers don't support it.
* Sanitizing JavaScript from HTML by blacklisting isn't simple operation. Possibly attack vector. (for web mail)
Seems like a solved problem considering there's currently no way to execute arbitrary javascript in webmail.
Background image with url() is very easy to be whitelisted because it's very similar to <img> tag.
> Does this really increase the attack surface area, since you can't execute javascript from the iframe?
Sorry, this concern isn't about security for browsers, but for text editable email without indication. Maybe you can argue that it's not a problem because external image is already replaceable, but IMO it's more problematic.
> No, because that's not in the HTML/CSS spec and modern browsers don't support it.
Blacklist approach means that any tags just work unless explicitly specified on blacklist. "Not in spec" won't help.
> Seems like a solved problem considering there's currently no way to execute arbitrary javascript in webmail.
That's thanks to whitelist approach.
EPUB3 supports JS.