TL;DR.

In this post, I propose bending the format=flowed 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.

Background.

The 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 format=flowed 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 format=flowed emails.

(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 RFC5322.

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, my format=flowed configuration is shown below. The relevant variable in this case is of course fill-flowed-encode-column.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

;; enable format=flowed
;; - mu4e sets up visual-line-mode and also fill (M-q) to do the right thing
;; - each paragraph is a single long line; at sending, emacs will add the
;;   special line continuation characters.
;; - also see visual-line-fringe-indicators setting below
(setq mu4e-compose-format-flowed t)
;; because it looks like email clients are basically ignoring format=flowed,
;; let's complicate their lives too. send format=flowed with looong lines. :)
;; https://www.ietf.org/rfc/rfc2822.txt
(setq fill-flowed-encode-column 998)
;; in mu4e with format=flowed, this gives me feedback where the soft-wraps are
(setq visual-line-fringe-indicators '(left-curly-arrow right-curly-arrow))

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.