Plaintext Email Formatting

Faded write thumbnail. In the middle, a colorful mail envelope is hastily jotted. Before it, there’s “>” and there are “*” around it. These mimic plaintext email formatting. In the corners, there are “@@rt@k@” and “@artyom Bologov” attributions. Yeah, I know I went overboard with these.

Plaintext emails. This artifact of the times long gone, right? Not necessarily—plaintext emails are actively used in e.g. FOSS software mailing lists. And, if one’s into this type of communication, they’ll inevitably notice this: Plaintext email formatting. Asterisks, signatures, hyphenated lists.

Being a standard freak that I am, I wondered: are these spec-ed anywhere? No, not really. The only reasonable resource on plaintext email formatting I was able to find was this Ed Mullen’s post regarding Thunderbird/Mozilla Structured Text. And even that lists mere four formatting directives.

So I bit the bullet and decided I must list all the formatting conventions. With the support for these in all email clients I can get my hands on.

Sample Email #

Here’s a sample email I sent to myself to test formatting. The tested formatting comes mainly from Markdown and Org. And my meager experience reading emails on FOSS projects’ mailing lists.

# Heading

** Heading

* Heading
===================

Mozilla structured text:
*This text* is bold or otherwise emphasized
/This text/ should be italicized
_This text_ has underlines
|This text| should be formatted as code

Markdown conventions:
`This text` will maybe be formatted as code
`This text' is an old code convention, might work as well
Maybe +this text+ is crossed out?
Okay, ~this text~ must be crossed out

> Quote, a typical convention
> for listing the other’s text,
> usually coming from previous email.

Code blocks:

    int main()
    {
            // Put your code here:
            return 0;
    }

```
int main()
{
        // Put your code here:
        return 0;
}
```

Now, links:
[some link](https://aartaka.me)
<https://aartaka.me>
[[https://aartaka.me][some link]]

<pre>
  Some inline HTML
</pre>

-- 
Artyom Bologov
https://aartaka.me

Example email with formatting

Plaintext Formatting Support Across Clients #

And here’re the support tables for text-level elements:
Client Bold Italics Underline Code Strikethrough Link
Emacs Article.el ✅ ✅ ✅ ❌ ❌ ✅
Thunderbird ✅ ✅ ✅ ❌ ❌ ✅
Claws Mail ❌ ❌ ❌ ❌ ❌ ✅
Gmail ❌ ❌ ❌ ❌ ❌ ✅
Disroot Webmail ❌ ❌ ❌ ❌ ❌ ✅
MacOS & iOS Mail ❌ ❌ ❌ ❌ ❌ ✅
Email clients and their text-level formatting support

Email clients and their text-level formatting support
Client	Bold	Italics	Underline	Code	Strikethrough	Link
Emacs Article.el	✅	✅	✅	❌	❌	✅
Thunderbird	✅	✅	✅	❌	❌	✅
Claws Mail	❌	❌	❌	❌	❌	✅
Gmail	❌	❌	❌	❌	❌	✅
Disroot Webmail	❌	❌	❌	❌	❌	✅
MacOS & iOS Mail	❌	❌	❌	❌	❌	✅

And for block elements:
Client Heading Quote Code Inline HTML Lists Signature
Emacs Article.el ❌ ✅ ❌ ❌ ❌ ✅
Thunderbird ❌ ✅ ❌ ❌ ❌ ✅
Claws Mail ❌ ✅ ❌ ❌ ❌ ✅
Gmail ❌ ❌ ❌ ❌ ❌ ✅
Disroot Webmail ❌ ✅ ❌ ❌ ❌ ✅
MacOS & iOS Mail ❌ ✅ ❌ ❌ ❌ ❌
Email clients and their block formatting support

Email clients and their block formatting support
Client	Heading	Quote	Code	Inline HTML	Lists	Signature
Emacs Article.el	❌	✅	❌	❌	❌	✅
Thunderbird	❌	✅	❌	❌	❌	✅
Claws Mail	❌	✅	❌	❌	❌	✅
Gmail	❌	❌	❌	❌	❌	✅
Disroot Webmail	❌	✅	❌	❌	❌	✅
MacOS & iOS Mail	❌	✅	❌	❌	❌	❌

So Emacs and Thunderbird seem to respect the historic conventions. While others interpret plaintext emails more or less verbatim. With Gmail and Mail.app going as far as removing some essentials. A shame. Making one tiptoe around incompatibilities is not kind.

Safe Email Formatting Subset #

Given this spotty support for plaintext formatting, what should one use? Should they even? Regardless of the need for it, here’s what I consider safe to use for formatting in (plaintext) emails:

Bold/emphasis asterisks. Not all clients support that. But asterisks still are a conventional way to highlight text, including on platforms where there’s no formatting (like social media.) I don’t like italics and code notation from Mozilla Structured Text, while underline is kind of meaningless if you have emphasis. So I’m going to stand by only a single text-level element—asterisk emphasis.
Links. While they are not formatted in any way, they are highlighted by every client I tested. Putting them into <angle brackets> is a matter of etiquette, but it works alright regardless.
Quotes. Yes, Gmail ignores these, but they are still conventional enough. Essential even.
Signatures. Let’s ignore MacOS/iOS Mail for this one.
Hyphen/plus/asterisk lists. Not supported anywhere, but still a perfect way to make lists that would be readable to anyone. Being an editorial pedant, I might use en-dashes (“–”) instead, but that’s on me.

Note of caution on text-level elements

I can’t stop saying this, so here we go again: Don’t use text-level elements in HTML and elsewhere! They are not announced by screen readers and introduce a lot of clutter. Better use literary methods for emphasis and other purposes. But who am I to stop you? Go all in on bold and underline if you must.

This post and these formatting elements are not much, but at least email formatting is a charted path now. (I sure would’ve benefited from a post like this joining GNU and Suckless mailing lists.) I hope I helped you understand what plaintext emails can and cannot do. Good emailing!

Update: Inline HTML! #

Most (all?) email clients support multipart/mixed emails. Which means that one can get away with inline HTML if they do proper boundary setting in emails! For Emacs, it will look somewhat like:

<#multipart type=mixed>
<#part type=text/plain>
This is a plain text part.
<#part type=text/html>
<pre>
  heloo
  there
</pre>
<center>This is a centered enriched part</center>
<#/multipart>
hello *there* _you_ /person/!

Emacs multipart email

For other clients, a more standard syntax of RFC 1341 MIME might work better:

Content-Type: multipart/mixed; boundary="HTMLHTMLHTML"

--HTMLHTMLHTML

This is a plain text part.

--HTMLHTMLHTML
Content-Type: text/html

    block
    block
    block


This is a centered enriched part
--HTMLHTMLHTML

hello *there* _you_ /person/!

--HTMLHTMLHTML--

MIME encoding for multipart emails

In any case, one can inject HTML into “plaintext” emails! Just that it’s a relatively obscure feature, forgotten and hidden as much as plaintext formatting.

Plaintext Email Formatting

Sample Email #

Plaintext Formatting Support Across Clients #

Safe Email Formatting Subset #

Update: Inline HTML! #

Leave feedback! (via email)