Last night I decided to test how viable it would actually be to have an email chain among friends, with only some of them using deltachat. I bumped into a strange issue: deltachat was inserting hard newlines in my messages, seemingly at random, which causes other mail clients to fail to reflow the text. The newlines are particularly apparent on a cell phone, where narrow interfaces result in a mess of both soft and hard linewraps. What’s more, deltachat itself does not render the newlines it was creating. What a strange bug!
Eventually I did arrive at what is probably the correct conclusion: this is the effect of format=flowed. My current understanding of format=flowed may be flawed and I am open to being corrected. That being said:
I think format=flowed is bad, and always has been.
The RFC claims it is a transparent solution to the problem of “embarrassing line wrap.” But that is demonstrably not true, at least in deltachat’s implementation.
Deltachat’s f=f subtly mangles the sender’s text formatting.
The receiving client cannot unmangle the message without support for f=f.
This is not transparent, and in fact it’s rather rude. It also creates the very problem it’s trying to solve.
I realize I’m probably stepping into a hornets nest, but given that f=f is really, truly obscure: please disable f=f in order to prevent improper rendering in other clients.
Related. New thread because a request for toggle is imo not sufficient. Needs to be off by default. Toggleable format=flowed support
Both screenshots on the left are of deltachat desktop for Windows 1.48.0 (git: v1.33.0-1164-g350bdc07), however I can confirm they appear the same on android 1.48.3.
The top right screenshot is the raw eml (obtained from fastmail web interface). Bottom right is the desktop popup from the adjacent screenshot’s “show full message”. No particular reason I chose that over the raw eml.
Deltachat desktop for Windows and deltachat android both send f=f. (as seen in upper screenshots)
I used fastmail web interface to send the message pictured at the bottom. Amusingly, fastmail doesn’t try to stay within 80 columns. Fastmail’s web client just sends the text as is, presumably preserving lines right up until the relevant RFC’s limit of ~1000 columns.
You likely know this, but I’ve only just learned that quoted printable, which predates f=f, can be used to keep column counts short (if it is desired to stay within the relevant RFC’s SHOULD). Much like f=f, qp has syntax (=CRLF) to denote that a line should be joined with the following line. However instead of requiring special parsing, it just becomes one normal line and normal line wrapping occurs. An f=f like experience can be implemented at this point without tampering with the contents of the message.
…which leads me to the conclusion that f=f largely functions as a means to hardcode a certain formatting preference, and make everyone else write extra code to handle it. Extra work for thee, not for me.
Ironically I first noticed f=f causing problems in a terminal email client I was testing: aerc. f=f support not supplied in an actively developed modern terminal client!
Plus, deltachatters are rather less to be messaging terminal f=f diehards, than anyone else. f=f doesn’t seem to pose a benefit here.
I sent that shortly after I noticed the problem. I was aware of f=f prior to this but not very familiar with it. My initial assumption was that there was a bug here, especially considering that I kept seeing the statement that f=f should not be paired with qp. I think f=f’s RFC even says that.
However when I properly understood what qp and f=f are, it became clear that the combination of them was not the problem nor is this a “bug”; it’s f=f working as intended. I think, anyway.
