OT: Long lines in email (was: Re: special bg color)

[Duncan]

Boyd Stephen Smith Jr. posted on Thu, 24 Dec 2009 10:16:14 -0600 as
excerpted:

> In <20091224085352.403b4f3a at 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.