HTML E-Mails are a security nightmare, even if "only" CSS is "allowed" and JS/iframes/external images are not loaded.
Factoid of the day: Netscape added support for a <blink> tag to text/enriched bodies, and that support remains in every client that's still using Netscape's MIME code. The comment above this code just says: "Of course, both text/richtext and text/enriched must be enhanced somehow... Or else what would people think."
> There are other text formatting standards which meet some of these criteria. In particular, HTML and SGML have come into widespread use on the Internet. However, there are two important reasons that this document further promotes the use of text/enriched in Internet mail over other such standards:
> 1. Most MIME-aware Internet mail applications are already able to either properly format text/enriched mail or, at the very least, are able to strip out the formatting commands and display the readable text. The same is not true for HTML or SGML.
> 2. The current RFC on HTML [RFC-1866] and Internet Drafts on SGML have many features which are not necessary for Internet mail, and are missing a few capabilities that text/enriched already has.
> For these reasons, this document is promoting the use of text/enriched until other Internet standards come into more widespread use. For those who will want to use HTML, Appendix B of this document contains a very simple C program that converts text/enriched to HTML 2.0 described in [RFC-1866].
It sounds to me like text/enriched was being proposed not so much as a replacement for HTML, but because HTML and related technologies were not yet mature enough. This wording expressly frames text/enriched as a stop-gap measure.
https://github.com/mozilla/releases-comm-central/blob/master...
Try out the online examples.
Having email rendered consistently across many email clients was the main reason we stayed with Mail Chimp for so long...
The actual markup MJML generates is terrifying, and can be very large payloads. A simple hero graphic, some styled body text, a few buttons, and a footer was around 60KB/message. It got gnarly for us as our MTA had a max-payload size per API 'send' call (Mandrill) so our max send rates were partially constrained by MJML's fat markup.
But totally worth it to not spend _as_ much time satisfying the mail clients of the world.
Things feel a little stale.
For example (from this week of my adventures with Foundation for Emails) Google Fonts almost sort of work for email, but there's just no real easy way to tell this framework to use them, or call any web font.
I mean, different mime versions of the same content are a possibility to do this transition: Send both plaintext, HTML and markdown, and the receiver could choose to display markdown if he otherwise would display plain text.
To be honest, this won't come. Google is pushing AMP into mails, that's exactly the opposite direction.
This has been discussed before with regard to external links to images. I think that always made sense, but it makes even more sense to do this when the core content is external. Then fetching it would be just another part of the SMTP/HTTP transaction sequence to deliver a mail.
(Actually, thinking further it would have to be done server side to avoid leaking your personal IP. For a webmail provider that’s obviously straightforward, while IMAP servers could be extended to automatically replace AMP email directives with a static HTML attachment.)
The first stage of spam filtering, and greylisting, also reject at SMTP transmission time.
I'd do the HTTP fetch when SMTP is about to accept the message, making the HTTP round trip just another part of the transaction.
Since spam filtering is likely to look at the HTTP response, you might want to reject the SMTP transaction after seeing the HTTP response, rather than accept the SMTP transaction based on address alone.
"The AMP version of the message is embedded into the email as a new MIME part, in addition to the HTML and plaintext, ensuring compatibility across all mail clients"
From https://amp.dev/documentation/guides-and-tutorials/start/cre...
I want to see email clients start to support Markdown, so I can just send it to everyone.
Markdown is also not any better than HTML in terms of security - most markdown parsers allow passing through arbitrary HTML, and then depend on sanitizing the HTML for security.
What you are asking for is effectively a smaller subset of HTML to be used for for email (which is kind of how it started...)
- You are correct that implementing markdown consistently is hard because there is no real spec. CommonMark is a spec, which helps, but a heroically thorough spec, so it's still not exactly trivial to implement.
- You are correct that markdown can escape to HTML. Indeed certain marketing email "features" probably would do this?
If I am missing something maybe someone could make an actual contribution to the discussion and explain.
In any case I think by far the most important point was made elsewhere: Google AMP is awful for the web and for email, both.
p.s. edit: Actually, I think the even more important point is that anything except plain text email is awful. :) So there, sure, use markdown or org-mode formatting conventions. Humans are pretty good at handling messy human protocols.
I've yet to see what I'd really like: preformatted text being surrounded by markers that make it easy to paste in, like so:
Some regular text
vvvvv
Preformatted text
^^^^^
From Gruber’s Markdown spec:
> Readability, however, is emphasized above all else.
Some regular text
```
Preformatted text
```
Markdown is fast to type for the majority of use cases since you have:
- bullet points
- headings
- __bold__
- __italic__
- `inline code`
- etc
```
fn you_even(_have: &str) -> &str { "nifty little code blocks without needing to indent" }
```
And more importantly, markdown syntax preserves the structure of the document without harming legibility, unlike say latex or HTML. That limits it, since the syntax is small, but also reduces friction in learning/writing markdown.
Also, Reddit + GitHub.
I thought hacker news used markdown, but I guess has its own thing.
I can see the severely constrained formatting options of hacker news has both positive and negative consequences.
I've used it on several projects, it speeds things up quite a bit