[MlMt] Prevent line wrapping in plain text emails

[Bill Cole]

On 18 Nov 2013, at 11:54, Sherif Soliman wrote:

> Hello everyone, I'm a new user and I'm trying to set up MailMate to be 
> my permanent mail client, so apologies if this is answered somewhere 
> else. I tried searching and came up with nothing.
>
> Is there a way to stop MailMate from hard wrapping plain text replies 
> and quoted blocks to 72/73 characters? I've always strongly disliked 
> that and I really, really need to stop that from happening. It is 
> almost a deal-breaker for me, so I really hope there is some way to 
> turn that off. Judging from the number of emails I've received from 
> the MM mailing list, I'm hopeful there is a way.
>
> Any help would be appreciated. Thanks.

I don't know exactly what you're looking for or whether MM can be made 
to do it, but this is probably related to the fact that MM uses the 
"format=flowed" version of text/plain messages as defined by RFC3676 
(http://www.ietf.org/rfc/rfc3676.txt) (which is derived from the earlier 
definition in RFC2646)

The issues that led to the definition of format=flowed are discussed in 
detail in RFC3676 and RFC2646. In "raw" form, a format=flowed message 
has lines of 79 or fewer characters, preserving backwards  compatibility 
with old and/or MIME-ignorant tools that expect email to suit the 
traditional 80-column terminal format. However, the use of format=flowed 
in the MIME Content-Type header for a message tells any reasonably 
modern MIME-aware mail client that those apparently "hard wrapped" lines 
follow the RFC3676 rules that make it possible for the client to reflow 
the text (including quoted text) to fit its own presentation needs.

The alternative approach used in some mail clients of using a single 
logical line per paragraph (with Base64 or Quoted-Printable encoding 
used to protect that format in transit) has a long history of 
dysfunction and is compatible across mail tools based primarily on their 
ability to copy and/or interpret each other's quirks. There is no formal 
specification of how clients should reflow decoded text with very long 
lines to fit or overflow a rendering window, and by strict 
interpretation of past and current standards (i.e. what RFC3676 
describes as "format=fixed") a client shouldn't engage in "soft 
wrapping" of long lines. One result of clients using the misguided 
line-per-paragraph format can be seen in many web-accessible archives of 
mailing lists with many users of those broken mail clients: the text of 
their messages runs off the right side and you have to scroll over to 
read it all. The saddest examples of this are at lists.apple.com, 
because Apple made the spectacularly stupid choice a few years ago to 
switch Mail.app from generating format=flowed messages to mimicking 
older versions of Outlook. Ironically, MS almost simultaneously added 
RFC3676 support to Outlook, leaving Mail.app the unchallenged champion 
of non-standard mail formatting among current clients.