Giving up on format=flowed

I’ve been a long-time advocate of the format=flowed convention, as described in RFC 3676, for formatting e-mails. Two years ago I was describing how to use that convention with Neomutt and Vim.

However, I’ve now come to the conclusion that it was time to give up.

Lack of support

Though the format=flowed specification has been published in 2004, eighteen years later, it is still only supported by a handful of mail clients.

Nowadays, you can count yourself lucky if your mail client allows you just to compose an e-email in plaintext! You’re even luckier if it can automatically wrap long lines for you (something that text editors have been able to do since probably before I was born, but that some mail clients still can’t figure out how to do)!

Asking your email client to support something so complicated as format=flowed (instead of something super simple and easy to implement, like, you know, HTML and CSS) is, seemingly, just asking too much.

The dice are cast. Either your email client has implemented format=flowed, in which case it probably did so a long time ago, or it has not, in which case it is highly unlikely it will ever do so — the RFC 3676 will now be considered an old (as in: deprecated, obsolete, for-old-folks-only) document and no new developer will ever be convinced it is worth implementing.

What to do, then?

Using HTML is, of course, not an option.¹

Hard line breaks?

The first option is to always use hard line breaks. Follow the good old netiquette, and always wrap your lines (possibly using the automatic wrapping feature of your mail client’s composer window, if it has such a feature) so that they’re never longer than a given fixed width (the netiquette recommends 65 characters, to allow for multiple levels of quoting before reaching the 78-characters soft limit).

The obvious problem with this option is the problem that format=flowed was designed to solve: since your email now contains only hard line breaks, your recipient’s email client cannot re-flow the text as needed to fit it into its window — it has no way of knowing which line breaks were only inserted for wrapping purposes (and so, were actually intended as soft line breaks), and which line breaks are actually significant (“real” hard breaks).

It’s not too bad if your email is displayed in a window large enough to accomodate at least 65 characters per line — though people with large monitors might still be a bit annoyed. It is quite bad, however, if it is displayed on a smaller window which can only display less than 65 characters (on a smartphone for example). The mail client will have to insert additional soft line breaks (to avoid horizontal scrolling), and the result will typically be quite messy and not nice to read.

No line breaks

The other option, which is the one I think I will be using from now, is to forget about line wrapping completely. Write an entire paragraph as a single line, as long as it needs to be. Do not insert any soft line break. Let the email client deal with wrapping the text when it reaches the right border of the window, however narrow or large the window may be.

If you are familiar with email standards, you might think that such an advice could run afoul of a particular constraint of the SMTP protocol: namely, that a line in a SMTP exchange MUST be no more than 998 characters, and SHOULD be no more than 78 characters (RFC 5322, §2.1.1). Surely, if you write your paragraphs in a single line, you will exceed the 78-characters limit and thus violate a SHOULD rule (bad!); you may even at some point exceed the 998-characters limit and thus violate a MUST rule (very bad!). So that’s a very bad idea, isn’t it?

Not quite.

I contend that, in 2022, you should not be worried about something as low-level as the line length limit of the SMTP protocol. Let your mail client deal with such things, it will do so better than you — and if it does not, change your email client!

Email clients can deal with long lines the same way they have dealt with non-ASCII characters or binary attachments for ages: by encoding your text, to put it in any suitable form to be sent through the SMTP protocol.

For example, the Quoted-Printable encoding will do just fine:

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus elit, ve=
stibulum ut, placerat ac, adipiscing vitae, felis. Curabitur dictum gravida=
 mauris. Nam arcu libero, nonummy eget, consectetuer id, vulputate a, magna=
. Donec vehicula augue eu neque. Pellentesque habitant morbi tristique sene=
ctus et netus et malesuada fames ac turpis egestas. Mauris ut leo. Cras viv=
erra metus rhoncus sem.

No lines are longer than 78 characters, so no SMTP rules are broken. And don’t worry about the recipient being annoyed by those extra = characters: they won’t see them! What your email client has encoded automatically, their client will decode automatically!² What the recipient will actually see will be a single logical line, which will be wrapped as needed to fit into the window, no matter how narrow or large that window may be:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus elit, vestibulum ut, placerat ac, adipiscing vitae, felis. Curabitur dictum gravida mauris. Nam arcu libero, nonummy eget, consectetuer id, vulputate a, magna. Donec vehicula augue eu neque. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Mauris ut leo. Cras viverra metus rhoncus sem.

1. ↑ Hey, if I were the kind of people to use HTML in email, I wouldn’t be the kind of people to care about things such as format=flowed.
2. ↑ Unless their email client does not understand the Content-Transfer-Encoding header, but if so, quite frankly, it’s their problem, not yours!

29 August 2022