In its earliest days, email was an entirely text based affair. There was no bold or italic, no headings, no fonts; just text.
Even more than that, the text itself had particular constraints. The email standard says that lines should be no longer than 78 characters, though things like quoted printable do allow logical lines longer than this. Historically however, emails were hard wrapped (that is, a line break was inserted) after at most every 78 characters, usually at a word boundary.
Additionally, there were conventions on what should be done with text from previous emails when you replied to them, namely that each line you included should be “quoted” with a
> prefix, so you end up with levels like this:
> > How about dinner?
> Sounds great. Where?
How about Il Solito Posto?
This works fine for short lines, but when you have blocks of longer text and multiple replies back and forth, prefixing
> at the start of each reply line can push it to longer than 78 characters, which then gets wrapped again. Repeated a number of times, this can result in a mess of randomly wrapped and quoted lines, colloquially known as “embarrassing line wrap”.
A while back, there was an interesting attempt to fix this known as format=flowed. The standard itself is sort of neat, in that it applies a logical quoting construct in a backwards compatible manner to text emails. A receiver without format=flowed support sees a normal email and can reply as normal, though they may end up with embarrassing line wrap, but a format=flowed aware receiver will correctly re-wrap the further quoted sections when you reply, to ensure the lines are shorter than 78 characters but without the messy wrapping.
This was one of those standards we were always interested in implementing, but it never got high enough up the priority list.
Unfortunately, having had a look again, I donʼt think itʼs likely weʼll ever do it, for a couple of reasons:
<blockquote> construct to create reply structures, which correctly re-flows any text within it.
On top of that, there are two significant implementation issues to deal with:
Put together, all of these things make format=flowed a standard that doesnʼt feel worth implementing any more. In some respects thatʼs a real pity, but in others, itʼs just another sign that things have moved on. In yet another area, HTML has mostly won, and there are only a couple of places (mostly technical communities) where people still use text only emails.
Fastmail’s open API makes creating new and exciting tools easy for email enthusiasts.
At the beginning of December, we announced the return of Fastmail Advent. Please enjoy this wrap-up of our staff members’ responses.