
\documentclass[12pt]{article}
\usepackage[T2A,OT1]{fontenc}
\usepackage[default]{cantarell}
\usepackage[a4paper, top=20mm, bottom=20mm, left=20mm, right=20mm]{geometry}
\usepackage[utf8]{inputenc}
\usepackage[russian, english]{babel}
\usepackage{tabu}
\usepackage{hyperref}
\usepackage{parskip}
\usepackage{graphicx}
\usepackage{tabularx}
\usepackage{float}
\floatstyle{boxed}
\restylefloat{figure}
\usepackage{setspace}
\onehalfspacing
\author{Artyom Bologov}
\date{\today}
\title{Plaintext Email Formatting}
\makeatletter
\def\endenv{\expandafter\end\expandafter{\@currenvir}}
\makeatother
\begin{document}
\maketitle

\includegraphics[width=\textwidth,height=\textheight,keepaspectratio]{./assets/email-formatting.png}

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
\href{https://edmullen.net/mozilla/moz_stext.php}{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.

\section*{Sample Email} \label{sample}

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.

\begin{figure}[h!]\begin{verbatim}
# 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
\end{verbatim}\caption{Example email with formatting}\end{figure}

\section*{Plaintext Formatting Support Across Clients} \label{support}

And here’re the support tables for text-level elements:

\begin{table} \begin{tabularx}{0.8\textwidth}
\hline Client & Bold & Italics & Underline & Code & Strikethrough & Link \hline \\ \hline
Emacs Article.el & ✅ & ✅ & ✅ & ❌ & ❌ & ✅ \\
Thunderbird & ✅ & ✅ & ✅ & ❌ & ❌ & ✅ \\
Claws Mail & ❌ & ❌ & ❌ & ❌ & ❌ & ✅ \\
Gmail & ❌ & ❌ & ❌ & ❌ & ❌ & ✅ \\
Disroot Webmail & ❌ & ❌ & ❌ & ❌ & ❌ & ✅ \\
MacOS \& iOS Mail & ❌ & ❌ & ❌ & ❌ & ❌ & ✅ \\
\end{tabularx} \caption{Email clients and their text-level formatting support} \end{table}

And for block elements:

\begin{table} \begin{tabularx}{0.8\textwidth}
\hline Client & Heading & Quote & Code & Inline HTML & Lists & Signature \hline \\ \hline
Emacs Article.el & ❌ & ✅ & ❌ & ❌ & ❌ & ✅ \\
Thunderbird & ❌ & ✅ & ❌ & ❌ & ❌ & ✅ \\
Claws Mail & ❌ & ✅ & ❌ & ❌ & ❌ & ✅ \\
Gmail & ❌ & ❌ & ❌ & ❌ & ❌ & ✅ \\
Disroot Webmail & ❌ & ✅ & ❌ & ❌ & ❌ & ✅ \\
MacOS \& iOS Mail & ❌ & ✅ & ❌ & ❌ & ❌ & ❌ \\
\end{tabularx} \caption{Email clients and their block formatting support} \end{table}

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.

\section*{Safe Email Formatting Subset} \label{safe}

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:

\begin{itemize}\item 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.
\item 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.
\item Quotes.
  Yes, Gmail ignores these, but they are still conventional enough.
  Essential even.
\item Signatures. Let’s ignore MacOS/iOS Mail for this one.
\item 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.
\end{itemize}

\paragraph{Note of caution on text-level elements} \begin{quote}
I can’t stop saying this, so here we go again:
\href{https://tpgi.com/screen-readers-support-for-text-level-html-semantics}{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.
\end{quote}

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!

\section*{Update: Inline HTML!} \label{upd-inline-html}

Most (all?) email clients support \verb|multipart/mixed| emails.
Which means that one can get away with inline HTML if they do proper boundary setting in emails!
\href{https://gnu.org/software/emacs/manual/html_mono/emacs-mime#Simple-MML-Example}{For Emacs, it will look somewhat like:}

\begin{figure}[h!]\begin{verbatim}
<#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/!
\end{verbatim}\caption{Emacs multipart email}\end{figure}

For other clients, a more standard syntax of
\href{https://w3.org/Protocols/rfc1341/7_2_Multipart.html}{RFC 1341 MIME}
might work better:

\begin{figure}[h!]\begin{verbatim}
Content-Type: multipart/mixed; boundary="HTMLHTMLHTML"

--HTMLHTMLHTML

This is a plain text part.

--HTMLHTMLHTML
Content-Type: text/html

<pre>
    block
    block
    block
</pre>

<center>This is a centered enriched part</center>
--HTMLHTMLHTML

hello *there* _you_ /person/!

--HTMLHTMLHTML--
\end{verbatim}\caption{MIME encoding for multipart emails}\end{figure}

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.

\par\noindent\rule{\textwidth}{0.4pt}
Copyright 2022-2025 Artyom Bologov (aartaka).
Any and all opinions listed here are my own and not representative of my employers; future, past and present.

\end{document}
