Boyd Stephen Smith Jr. posted on Thu, 24 Dec 2009 10:16:14 -0600 as
excerpted:
> In <20091224085352.403b4f3a@o>, spir wrote:
>>Matthew Woehlke dixit:
>>> Also you might want to consider fixing your mailer to wrap long lines
>>> properly (or using a mailer that does).
>>
>>My mail client is correctly set to soft-wrap long lines, instead of
>> hard-wrapping (inserting newlines) them, so that text nicely adapt to
>> reader-chosen width (*).
>
> Your client is doing it wrong, then. If you client would like to
> soft-wrap lines, it should follow conventions established in RFC 3676
> (format=flowed). Currently your client is sending a mail message with
> lines longer than 80 characters, which is a violation RFC 5322 (Internet
> Message Format).
It's not a violation, as long as the MUST requirement of no more than 998
characters per line (1000 minus the terminating CRLF sequence) is met.
It may not meet the SHOULD of 78 chars, but it DOES meet the MUST of 998
chars. Quoting the relevant section 2.1.1 of the RFC you named:
"""""
2.1.1. Line Length Limits
There are two limits that this specification 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
that send, receive, or store IMF messages which 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 that
(in compliance with the transport requirements of [RFC5321]) do not
accept messages containing more than 1000 characters 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 [RFC5321] if they actually cause
information to be lost). Again, even though this limitation is put
on messages, it is incumbent upon implementations that 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.
"""""
In light of that, the best clients will allow a /reader/ to toggle the
line wrap three ways: (1) to window/display width (this could well be a
variable number of characters if a non-fixed-width font is used), (2) to
the fixed width of no more than 78 chars as specified as the SHOULD, and
(3) to the width as the sender sent it, that is, the "raw" width, in case
there's line-wrap specific content (like say programming code) included.
Good (as opposed to best, above, and poor, below) clients will allow
toggling between at least #3 (width as sent) AND ONE of the other two,
either the 78 char standard, OR the width of the display or display
window as appropriate.
Poor clients will hard-code ONE of the above, either forcing horizontal
scrolling, if they don't do any wrapping on still-compliant lines as sent
up to 998 chars, OR screwing up the display of line-wrap specific content
such as programming code. They will still comply with the RFC as long as
they can take upto 998 char lines without losing content, but they are
poor clients in that they *WILL* cause the user fits in ONE of the cases
above, either causing unnecessary horizontal scrolling in the case of up
to 998 char lines, or destroying the meaning of line feeds where that
information is critical to the message content.
Non-conformant clients will actually fail to display content with many
conformant messages, or will send messages longer than 998 chars in raw
format. In the old days, this usually took the form of arbitrarily
chopping off messages at the 78 char boundary, with no option for
horizontal scrolling. Luckily, these clients tend to be few and far
between, as users tend to migrate away from them rather quickly. Now
days, it's possible that non-conforming clients allowing more than 998
chars per raw sent line are more common than the above "choppers".
FWIW, it's been awhile since I checked, but I believe both news and mail
message /headers/ are limited to 80 char lines (78 plus terminating CRLF)
in raw format (there's a wrapping spec), but message /bodies/ only have
the 1000 char line limit (998 plus terminating CRLF) MUST, tho they
SHOULD also follow the 80 char (78 plus terminating CRLF) SHOULD.
However, clients MUST be able to handle 1000 char (998 + CRLF) line
bodies or they are NOT compliant. Similarly, they MUST limit body lines
to 1000 chars (998+CRLF) or they are not compliant, with the 80 char (78
+CRLF) limit a SHOULD, not a MUST.
(FWIW, one of the reasons I use pan as a news client -- I read this list
as news thru gmane.org -- is that it complies not only with the RFCS, but
also with the GNKSA, to 100% including the SHOULDs. As such, it fits in
the "good client" category above, allowing toggling between #2 and 3
above, 78-char and raw-width. I honestly don't know what kmail does, but
I have a reasonably wide display window, and don't get so much mail there
as all the lists are thru pan, so it hasn't bothered me, whatever it
does. I do wish it would show attached images (NOT ones that have to be
fetched!), tho, even in no-html mode, say below the message. That's what
pan does and it works quite well. Of course, knode has issues with this
sort of thing, or did, last I looked at it, the reason I don't use it.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
