> > > - You could use format=flowed email; paragraph lines that you want to > > > autoflow properly have to end in a SP CRLF sequence. That is defined > > > in RFC 2646. > > > > Obsoleted by RFC 3676. https://www.rfc-editor.org/info/rfc3676 > > > > From a quick glance, it insists ‘>’-quoting has no spaces. > > > > >>> This is quoted three deep. > > > > > > > This is only one deep. The unquoted text starts ‘> > This’. > >So you're saying they created a new standard that completely ignores >existing well-established practice, and makes the result less >readable, to boot? Well done. Oh! I see from the abstract that it >also relies on trailing whitespace! Clever.
It's only "new" if you consider that it was first created ... 26 years ago? RFC 2646 was published in 1999, and as Ralph pointed out it was obsoleted by RFC 3676 which came out in 2004. And I don't make the news, I just report it. And sadly, some further tests show me that it seems like the fastmail webmail app don't really support format=flowed after all. My gut suggests to me that there might have been a time when format=flowed was useful but I am not sure that time is now. >From where I'm sitting, here's the state of the world: - If there's an established practice for how to display the traditional text/plain, 72 column format email, I am unaware of it and as far as I can tell nobody bothered to write a standard practice down. It seems like the choices are, "treat it like paragraphs and autoflow it accordingly", or "wrap it when the line gets too long but treat each CRLF as a hard break". A very very brief survey suggests to me that most MUAs do the latter. - If you want to have text/plain email "nicely formatted" for non-nmh users, it seems like your only portable choice is to use quoted-printable and make each paragraph one long line. - The other most portable option is to probably start generating HTML email. Don't get me wrong, plain old 72-column text/plain email is still readable by everyone; it's just going to look ugly on modern MUAs. Whether or not you care about that is more of a matter of personal preference. Given that's the state of the world today, exactly how would people like to approach it? From where I am sitting, some possible options are: a) Do nothing b) Add some support to mhbuild to take paragraphs and munge them into long lines using q-p encoding. c) Add some support to mhbuild to generate a basic HTML-encoded email from plain text by separating paragraphs with <p> and possibly a few other things. b) and c) would be optional, of course. I am open to other suggestions! --Ken
