Hi Puneet-
Thanks for the replies. This is a section from some Thunderbird
documentation that points to a discussion about the origin of
the problem with flowed format from
http://kb.mozillazine.org/Plain_text_e-mail_%28Thunderbird%29
Flowed format
...
Some other e-mail clients don't format outgoing e-mails in accordance
with the standard. When replying in plain text, quotes may appear as
a single line per paragraph (see this forum thread,
http://forums.mozillazine.org/viewtopic.php?t=620097#3219442
Of course, I have no idea what could be done about it
and since for Mac<->Mac users, there is no visible
problem, I'm not expecting a huge call from the masses
to fix the problem. :-)
Cheers,
Chris
On 12/23/2011 12:11 AM, Mr. Puneet Kishor 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..."
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
