6 ms·

It would be really nice to have a small and simple markup language, say some markdown standard, to be the layouting language for E-Mails. No (external) images,

by ktpsns 7y ago

It would be really nice to have a small and simple markup language, say some markdown standard, to be the layouting language for E-Mails. No (external) images, just links, lists, headings, basic formatting. HTML E-Mails are a security nightmare, even if "only" CSS is "allowed" and JS/iframes/external images are not loaded.

gpvos 7y ago
Something like this? http://www.rfc-editor.org/rfc/rfc1896.txt http://www.rfc-editor.org/rfc/rfc1896.txt
- ktpsns 7y ago
  Thanks for the RFC link. Yes, basically. 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.
  - sjwright 7y ago
    It’s so stupid. If AMP emai ever became a thing, every single non google email client would just fetch and store the contents of the AMP page the moment an AMP email arrives. So what was the point of it?
    - rypskar 7y ago
      Not so sure about that, not downloading anything extra and only showing what is embedded in the email is one of the good things with using an email client. Using AMP email is back to thinking tracking pixels works in emails
      - jlokier 7y ago
        If the content isn't inline, perhaps it's better to have the mail server fetch it when the email is received, so that the sender can't track whether you are reading it. 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.
        sjwright 7y ago
        Exactly. If most mail clients downloaded it automatically upon receipt instead of on view then the tracking benefits get diluted to the point of uselessness. (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.)
        jcranmer 7y ago
        So you want RFC 2017 basically?
        sjwright 7y ago
        No, I want AMP email to never happen. Failing that, I want the email server to un-AMP-ify incoming emails for me.
        rypskar 7y ago
        Should it do that for all emails sent to the domain, or only for valid addresses? If they only fetch for addresses in use this will open up for an easy way for spammers to verify if an address is in use or not
        jlokier 7y ago
        Spammers can already verify if an address is _accepted_ because their message will be rejected with an error code at SMTP transmission time if it isn't. 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.
  - psimyn 7y ago
    Isn't AMP for email kinda what you are describing? "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/create_email/ https://amp.dev/documentation/guides-and-tutorials/start/cre...
  - yuft 7y ago
    Isn't markdown just turned into html?
- Moru 7y ago
  Email is so fun, every time someone comes with a new idea, someone pulls out an RFC detailing it. Dated 20+ years back.
  - gpvos 7y ago
    It even has a predecessor from 1992, see paragraph 7.1.3 of http://www.rfc-editor.org/rfc/rfc1341.txt http://www.rfc-editor.org/rfc/rfc1341.txt .
- bscphil 7y ago
  Markdown strikes me as a much improved version of exactly this, with the advantage that you don't have to have a supporting client to read the email, since it's simply plain text. I want to see email clients start to support Markdown, so I can just send it to everyone.
  - captn3m0 7y ago
    Not just email, I’d like to see browsers support Markdown natively. You can style your content. All media sites can be 100% markdown without any JS.
aloisdg 7y ago
Beside, I am using Markdown in all my email thanks to https://markdown-here.com/ https://markdown-here.com/ and Thunderbird
- dngray 7y ago
  Markdown Here appears to be unmaintained and is certainly incompatible with Thunderbird 68.0. I have not been able to raise the developer of it at all and PRs are not being merged. https://github.com/adam-p/markdown-here/issues/577 https://github.com/adam-p/markdown-here/issues/577
- zczc 7y ago
  The idea behind Markdown Here is good, but it has some issues like keeping a copy of the markup text base-encoded in some html attribute which can be lead to unintentionally leaking full text while forwarding part of the message.
matharmin 7y ago
Markdown is nice for composing, but not as a standard to be supported by many clients. CommonMark is an improvement, but there is way to many ambiguities and differences in supported features over different markdown parsers for it to be feasibly used as a standard. 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...)
- greghendershott 7y ago
  Not sure why you're being down-voted. (As usual here, only clicking a down-vote button contributes little value.) - 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.
- jandrese 7y ago
  This is a bigger issue than most people care to admit. I post stuff to a number of different sites that support "Markdown" and not a single one agrees on even something a simple as how to format a hyperlink. I end up having to hit the help page on every site to remember which syntax they use, if they even support the feature at all. HTML might be "ugly", but at least it is consistent.
  - tzs 7y ago
    I wish there was a browser extension to handle that. It would provide an editing area that would allow you to edit using the same markup on different sites, and when you are done would translate to whatever markup format that site uses and fill in the site's edit area with that.
t0astbread 7y ago
This + multipart/alternative email and maybe something like uMatrix or similar firewall mechanisms in mail clients
cygned 7y ago
No markdown, but we had success with this one: https://mjml.io/ https://mjml.io/ Try out the online examples.
- pintxo 7y ago
  Thanks, looks like a great solution.
- gitgud 7y ago
  Wow, that's pretty cool, what's the consistency across different clients like? Having email rendered consistently across many email clients was the main reason we stayed with Mail Chimp for so long...
  - erichurkman 7y ago
    It's pretty good. A few clients are still PITA (looking at you, Outlook 2007 and Yahoo mail. You still have to do jump through hoops for accurate background images, or fancy things with borders. 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.
    - marpstar 7y ago
      I agree with all of this. When you really start to dig in to cross-client compatibility (and you observe what MJML does to provide it) you start to get a sense that NOT using a tool like MJML is a hopeless path.
- adamredwoods 7y ago
  We use https://foundation.zurb.com/emails.html https://foundation.zurb.com/emails.html It is essentially rows and columns, but the support has been great across Outlook and gmail, as well as mobile support.
hawski 7y ago
But isn't Markdown a sugar on top of HTML? When something does not fit Markdown one is supposed to write inline HTML.
vinniejames 7y ago
Try Foundation https://foundation.zurb.com/emails.html https://foundation.zurb.com/emails.html I've used it on several projects, it speeds things up quite a bit
jcranmer 7y ago
You're basically advocating for text/richtext (aka text/enriched), which was originally proposed explicitly as a replacement for HTML in email. It failed essentially because everyone who didn't want HTML wanted only plain text, and everyone who wanted something like HTML was happy to just use HTML. 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."
- chrismorgan 7y ago
  From RFC 1896: > 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.
- archgoon 7y ago
  Looks like the comment remains there. :) https://github.com/mozilla/releases-comm-central/blob/master/mailnews/mime/src/mimetric.cpp#L159-L169 https://github.com/mozilla/releases-comm-central/blob/master...
neop1x 7y ago
The idea of markdown is great because it it essentially a text. Even if the client would not support it, humans would be able to read it just fine. Much better and more secure than rich HTML. For example my email client won't display images by default and I am happy with that. Rich HTML should be on the web only IMO!

by ktpsns 7y ago

gpvos 7y ago

Something like this? http://www.rfc-editor.org/rfc/rfc1896.txt http://www.rfc-editor.org/rfc/rfc1896.txt

ktpsns 7y ago
Thanks for the RFC link. Yes, basically. 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.
- sjwright 7y ago
  It’s so stupid. If AMP emai ever became a thing, every single non google email client would just fetch and store the contents of the AMP page the moment an AMP email arrives. So what was the point of it?
  - rypskar 7y ago
    Not so sure about that, not downloading anything extra and only showing what is embedded in the email is one of the good things with using an email client. Using AMP email is back to thinking tracking pixels works in emails
    - jlokier 7y ago
      If the content isn't inline, perhaps it's better to have the mail server fetch it when the email is received, so that the sender can't track whether you are reading it. 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.
      - sjwright 7y ago
        Exactly. If most mail clients downloaded it automatically upon receipt instead of on view then the tracking benefits get diluted to the point of uselessness. (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.)
        jcranmer 7y ago
        So you want RFC 2017 basically?
        sjwright 7y ago
        No, I want AMP email to never happen. Failing that, I want the email server to un-AMP-ify incoming emails for me.
      - rypskar 7y ago
        Should it do that for all emails sent to the domain, or only for valid addresses? If they only fetch for addresses in use this will open up for an easy way for spammers to verify if an address is in use or not
        jlokier 7y ago
        Spammers can already verify if an address is _accepted_ because their message will be rejected with an error code at SMTP transmission time if it isn't. 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.
- psimyn 7y ago
  Isn't AMP for email kinda what you are describing? "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/create_email/ https://amp.dev/documentation/guides-and-tutorials/start/cre...
- yuft 7y ago
  Isn't markdown just turned into html?
Moru 7y ago
Email is so fun, every time someone comes with a new idea, someone pulls out an RFC detailing it. Dated 20+ years back.
- gpvos 7y ago
  It even has a predecessor from 1992, see paragraph 7.1.3 of http://www.rfc-editor.org/rfc/rfc1341.txt http://www.rfc-editor.org/rfc/rfc1341.txt .
bscphil 7y ago
Markdown strikes me as a much improved version of exactly this, with the advantage that you don't have to have a supporting client to read the email, since it's simply plain text. I want to see email clients start to support Markdown, so I can just send it to everyone.
- captn3m0 7y ago
  Not just email, I’d like to see browsers support Markdown natively. You can style your content. All media sites can be 100% markdown without any JS.

aloisdg 7y ago

Beside, I am using Markdown in all my email thanks to https://markdown-here.com/ https://markdown-here.com/ and Thunderbird

dngray 7y ago
Markdown Here appears to be unmaintained and is certainly incompatible with Thunderbird 68.0. I have not been able to raise the developer of it at all and PRs are not being merged. https://github.com/adam-p/markdown-here/issues/577 https://github.com/adam-p/markdown-here/issues/577
zczc 7y ago
The idea behind Markdown Here is good, but it has some issues like keeping a copy of the markup text base-encoded in some html attribute which can be lead to unintentionally leaking full text while forwarding part of the message.

matharmin 7y ago

Markdown is nice for composing, but not as a standard to be supported by many clients. CommonMark is an improvement, but there is way to many ambiguities and differences in supported features over different markdown parsers for it to be feasibly used as a standard. 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...)

greghendershott 7y ago
Not sure why you're being down-voted. (As usual here, only clicking a down-vote button contributes little value.) - 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.
jandrese 7y ago
This is a bigger issue than most people care to admit. I post stuff to a number of different sites that support "Markdown" and not a single one agrees on even something a simple as how to format a hyperlink. I end up having to hit the help page on every site to remember which syntax they use, if they even support the feature at all. HTML might be "ugly", but at least it is consistent.
- tzs 7y ago
  I wish there was a browser extension to handle that. It would provide an editing area that would allow you to edit using the same markup on different sites, and when you are done would translate to whatever markup format that site uses and fill in the site's edit area with that.

t0astbread 7y ago

This + multipart/alternative email and maybe something like uMatrix or similar firewall mechanisms in mail clients

cygned 7y ago

No markdown, but we had success with this one: https://mjml.io/ https://mjml.io/ Try out the online examples.

pintxo 7y ago
Thanks, looks like a great solution.
gitgud 7y ago
Wow, that's pretty cool, what's the consistency across different clients like? Having email rendered consistently across many email clients was the main reason we stayed with Mail Chimp for so long...
- erichurkman 7y ago
  It's pretty good. A few clients are still PITA (looking at you, Outlook 2007 and Yahoo mail. You still have to do jump through hoops for accurate background images, or fancy things with borders. 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.
  - marpstar 7y ago
    I agree with all of this. When you really start to dig in to cross-client compatibility (and you observe what MJML does to provide it) you start to get a sense that NOT using a tool like MJML is a hopeless path.
adamredwoods 7y ago
We use https://foundation.zurb.com/emails.html https://foundation.zurb.com/emails.html It is essentially rows and columns, but the support has been great across Outlook and gmail, as well as mobile support.

hawski 7y ago

But isn't Markdown a sugar on top of HTML? When something does not fit Markdown one is supposed to write inline HTML.

vinniejames 7y ago

Try Foundation https://foundation.zurb.com/emails.html https://foundation.zurb.com/emails.html I've used it on several projects, it speeds things up quite a bit

jcranmer 7y ago

You're basically advocating for text/richtext (aka text/enriched), which was originally proposed explicitly as a replacement for HTML in email. It failed essentially because everyone who didn't want HTML wanted only plain text, and everyone who wanted something like HTML was happy to just use HTML. 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."

chrismorgan 7y ago
From RFC 1896: > 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.
archgoon 7y ago
Looks like the comment remains there. :) https://github.com/mozilla/releases-comm-central/blob/master/mailnews/mime/src/mimetric.cpp#L159-L169 https://github.com/mozilla/releases-comm-central/blob/master...

neop1x 7y ago

The idea of markdown is great because it it essentially a text. Even if the client would not support it, humans would be able to read it just fine. Much better and more secure than rich HTML. For example my email client won't display images by default and I am happy with that. Rich HTML should be on the web only IMO!