The first time I saw this happen was in one of Karl's emails, I believe,
and I have always found it annoying. I've just never had the gumption to
say anything. :-)
On Dec 23, 2011 12:13 AM, "Mr. Puneet Kishor" <[email protected]> wrote:

> Hi Chris,
>
> In addition to format=flowed, the reason may be compounded by the
> following.
>
> See ยง2.1.1 in [http://www.ietf.org/rfc/rfc2822.txt].
>
> 2.1.1. Line Length Limits
>
>   There are two limits that this standard places on the number of
>   characters in a line. Each line of characters MUST be no more than
>   998 characters, and SHOULD be no more than 78 characters, excluding
>   the CRLF.
>
>   The 998 character limit is due to limitations in many implementations
>   which send, receive, or store Internet Message Format messages that
>   simply cannot handle more than 998 characters on a line. Receiving
>   implementations would do well to handle an arbitrarily large number
>   of characters in a line for robustness sake. However, there are so
>   many implementations which (in compliance with the transport
>   requirements of [RFC2821]) do not accept messages containing more
>   than 1000 character including the CR and LF per line, it is important
>   for implementations not to create such messages.
>
>   The more conservative 78 character recommendation is to accommodate
>   the many implementations of user interfaces that display these
>   messages which may truncate, or disastrously wrap, the display of
>   more than 78 characters per line, in spite of the fact that such
>   implementations are non-conformant to the intent of this
>   specification (and that of [RFC2821] if they actually cause
>   information to be lost). Again, even though this limitation is put on
>   messages, it is encumbant upon implementations which display messages
>   to handle an arbitrarily large number of characters in a line
>   (certainly at least up to the 998 character limit) for the sake of
>   robustness.
>
>
>
> Anyway, I will be happy to do whatever is needed on my side to make sure
> email goes out correctly. But, so far you are the only one who has
> complained, so we will have to do some more investigation.
>
>
> On Dec 22, 2011, at 10:51 PM, Mr. Puneet Kishor wrote:
>
> > Chris,
> >
> > I think what you are seeing is a result of `format=flowed` setting from
> Apple Mail.app. From the raw source of my email message
> >
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Here is one explanation [
> http://www.sirena.org.uk/log/2008/08/30/apple-mail-and-formatflowed/].
> There are many more such explanations.
> >
> > Afaik, my Mail.app is set to send only plain text, not a multipart (text
> and html) version, unless I add some stuff that necessitates a multipart
> version.
> >
> > When I view my own emails using gmail, I see no issues with text wrap.
> Of course, my email is hosted on Google apps, so the Goog's SMTP server
> might be doing some shenanigans as well, but maybe there is a simpler
> explanation. In any case, I will research more to ascertain of the problem
> is on my end or not.
> >
> > On Dec 22, 2011, at 10:06 PM, chm wrote:
> >
> >> All-
> >>
> >> I've seen recently an increasing number of postings
> >> to the perldl and pdl-porters lists that have problems
> >> with excessively long lines.
> >>
> >> After researching the problem, it appears to be the
> >> result of problems with a Mac mail program (don't know
> >> which one or why) but it is a bit annoying since the
> >> list archives also show the same problem (I've figured
> >> out how to work around the problem in my responses
> >> using the Thunderbird Edit->Rewrap option).
> >>
> >> If any Mac users know how to fix the mailer problem,
> >> I'm sure others would find the information useful.
> >> As a sort of work-around, maybe our list archives
> >> could be set to force-wrap the problem messages
> >> so things will be more readable.
> >>
> >> Cheers,
> >> Chris
> >> "one frustrated by reading excessively long line/paragraphs..."
> >
>
> --
> Puneet Kishor http://punkish.org
> science http://earth-base.org
> advocacy http://creativecommons.org
>
> "assertions are politics; backing them with evidence is science"
>
>
>
>
> _______________________________________________
> Perldl mailing list
> [email protected]
> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
>
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl

Reply via email to