In this post, I propose bending the
RFC by allowing lines up to the SMTP
limit of 998 characters, in order to improve the plaintext reading experience
for users of non-compliant email clients and services, such as GMail, FastMail,
Outlook and others.
format=flowed plaintext email convention described in
RFC3676 is an elegant method whereby
plaintext emails can be prepared in such a way so that they are wrapped
correctly on older email clients, but they can also be reflowed by modern
clients supporting that part of the standard.
Please see this compact summary of
in another blog post of mine if you would like to know how it works.
Unfortunately, for the largest part through the dominance and irresponsibility
of GMail in the world of email, most email clients do not correctly reflow
(I find it most disappointing that FastMail, my mail provider of choice, otherwise doing good work as one of the last remaining alternatives to the incumbents, has also chosen not to support format=flowed, and not even on the reading end.)
The upshot of this is that these sorts of emails, although standards-compliant, generally look quite terrible to the hapless users of above-mentioned email services.
As the non-compliant email providers and clients represent the largest share of
the world’s email users, it is clear that
format=flowed will remain largely
unsupported, and that we should consider modifying our sending behaviour to
accommodate the recipients of our emails.
format=flowed with long lines.
The work-around I propose here is to send
format=flowed with a maximum line
length of 998, as specified in section 2.1.1 of
A small set of older mail clients will probably not be able to wrap this correctly.
However, the few email clients that do support
format=flowed will reflow
these long paragraphs due to the standard, while the large majority of
non-compliant clients (I’ve tested the GMail web interface, the latest Outlook
desktop client and the FastMail web client) will dynamically reflow the long
plaintext lines simply because they are, well, too long.
In short, your plaintext email will be reflowed by a much larger group of recipients and therefore appear substantially less terrible on their displays.
Emacs mu4e configuration.
For the mu4e Emacs mail client,
format=flowed configuration is shown below. The relevant variable in this
case is of course
If you would like to apply this trick, you might have to take a deep dive into your MUA’s documentation and/or source code to find out where and how exactly to implement this.
Interestingly, Apple’s email clients, both on macOS and iOS, handle plaintext emails quite well.
Why not just send HTML emails?
Well, sometimes I do, when it actually makes sense, for example when I need to send syntax highlighted source code or math.
However, mostly it does not make sense to send a ball of non-standard HTML markup with questionable font choices, and then plaintext emails really are a better choice.
It would have been best if the big email players would have followed the standards, but they do not, and so we are left with no choice but to bend the standard ever so slightly.