Upon further examination, * SMTP standards do recommend lines shorter than 80 characters, but also=20 recommend a way of flowing plain text. * My originating email client (NOT the list software) wrapped my long=20 lines (inserting CRLF after SP) and applied the "format=3Dflowed"=20 content-type specifier so the recipient would unwrap them. This is an=20 internet standard for plain text email, specified originally in RFC 2646=20 in 1999, and superseded by http://www.ietf.org/rfc/rfc3676.txt . * "Content-type: ...; format=3Dflowed" is DESIGNED to allowed flowed text=20 in emails while maintaining proper quoting. It is supported by Outlook=20 Express, Thunderbird, Eudora, Pine, et al. To say that email is not=20 designed to flow seems wrong in the face of this content-type specifier=20 and popular MUA support for it. * The list software removed the "format=3Dflowed" specified from the=20 Content-Type header. This is the source of the misinterpretation. This=20 issue was logged as a bug in GNU Mailman and fixed in version 2.1.10.=20 This list runs 2.1.6. * The list software also chose to retransmit the message with=20 "Content-Transfer-Encoding: base64", which means the entire message=20 source is a block of opaque base64 encoding, making the original line=20 breaks completely meaningless during transport. If your mail client is=20 so broken, legacy, or unstandard that it can't deal properly with modern=20 SMTP and MIME standards, or you're reading "plain text" in a non-MIME=20 user-agent, you would have seen many lines of=20 "biB0aGUgUHJvZ3JhbSBmb3IgCkNsaW" due to the list server's re-encoding. My conclusions: - Flowed plain-text email is an internet standard. - The list software is due for an upgrade after which it will properly=20 handle it. - You probably aren't reading the "plain text" you thought you were;=20 this is why mail user agents exist. - Arguing that a gateway should remain broken because there are so many=20 broken gateways out there seems illogical to me. - I have run Mailman, and upgrading Mailman is pretty easy. I volunteer=20 to do so on the PICLIST installation if the administrator desires. Joe K On 11/19/2010 3:45 PM, Peter Loron wrote: > On Fri, 2010-11-19 at 15:44 -0500, Olin Lathrop wrote: >> Joe Koberg wrote: >>> By the way, is there ANY way to stop the list software from forcing >>> line wrapping at 80 columns? >> Simple, don't send long lines in the first place. >> >> Once again, if you want your message to be seen with the least disruptio= n by >> the most people, send it in PLAIN TEXT with lines not exceeding 80 >> characters. This should be obvious to those on a technical list, but >> apparently sometimes it needs to be repeated. >> >> >> ******************************************************************** >> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products >> (978) 742-9014. Gold level PIC consultants since 2000. > These days that's akin to saying "only send smoke signals". There's some > value to plain text email, but limiting lines to 80 characters these > days is just broken. The number of people reading (or doing anything) > with email software that can't properly handle lines> 80 characters > before a line ending is vanishingly small. This is mis-configured list > software. > > -Pete > --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .