Markdown Email

What? another type of email? Don’t we have enough? Relax, all your questions will be answered ;).

Many of us remember the old days of text only email, and are glad for some more meaning carried in our online exchanges. And so we use formatting, obviously HTML is the solution here right? Good improvement to content, lots of pretty colours and we can put any web content in there we want…

Very true – your emails can tell the other client how to show the text you have sent. How to format it, what font size it should be… what server to download images from and where to access those scripts to run inside their email client…

OK you see where this is going. HTML was a bad idea – what we really wanted is a way to mark up our content to convey meaning, addition of semantics you might say. Which is what Markdown was created for – so it’s about time we actually use the right tool for the job.

Sounds good, tell me more

Not only can we avoid the downsides of HTML and the weight of needing a full web stack in our email client – but also the following benefits:

  • Smaller emails, quicker to download
  • Font sizes will be controlled by user settings not sender preference
  • Fix issues of light mode / dark mode coloured text
  • Avoiding complexities of multiple different rendering engines

So really we should have been doing this ages ago – but how?

The markdown email format

Here you might be expecting the introduction of a new format – but alas no, it already exists – multipart MIME is already in use for HTML+text email sending. And so we can re-use existing parsing, and the textual fallback that it provides – see the following example:

From: Example Sender <send@example.com>
To:  Smarter Client <client@example.com>
Subject: Markdown Example
MIME-Version: 1.0
Content-type: multipart/alternative; boundary="email boundary" 

--email boundary
Content-Type: text/markdown; charset=us-ascii 

# Heading text

Body text of my **markdown** email!
--email boundary
Content-type: text/plain; charset=us-ascii

This is the plain text version of my email

--email boundary--

It really is that simple, a client can just add support for this MIME type and hook in a simple markdown renderer to show it inline. Best of all it will match the look of your system and scale according to your user preferences!