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

Reply via email to