[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] 78 column limit

From: Ken Hornstein
Subject: Re: [Nmh-workers] 78 column limit
Date: Tue, 04 Dec 2012 14:40:56 -0500

>So... do I conform to standards or make my my recipients unhappy? In passing
>I note that almost all the Email I get, not from address@hidden, has
>very long lines.

Let's look at the standard.  Specifically, the latest update to RFC 822,
RFC 5322.  It says:

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.

So as long as you're keeping it under 998, you're keeping it within the
hard limits of RFC 5322 (that limit really applies to SMTP).  Note that nmh
will happily send a message with >998 characters per line; whatever is in
the draft file just gets blasted to the SMTP server.  That's a violation
of the next paragraph of RFC 5322:

   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.

But I was (rather cheekily, I admit) talking about the next paragraph in

   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.

We can display stuff with lines >78; they just line wrap poorly.  Fixing
this is ... well, hard.  Take a look at mhl and you'll see what I mean.

I generally restrict my email to 78 columns or less, and I've never heard
from anyone that my emails look "jagged".  Maybe it looks jagged to everyone
and they're not saying anything; hard to tell.

But I have a question for you; does the emal you get that has really long
lines come in as text/plain with a 7bit encoding?  Or does it come in
as quoted-printable?  In my limited experience the former is rare; the latter
is common.  The reason I noticed is that replyfilter assumes that text/plain
with a 7bit (or 8bit) encoding is exactly how the sender wanted it to be
displayed and thus it will not run the message through "par" for formatting.
I did this because I was replying to a lot of messages with code in them
and par really chewed that text up.  In my experience people with long lines
generally used q-p or base64 or some other encoding.

So, what to do?  We'll, I'm not sure; with the current tools you're
going to make someone unhappy.  We don't right now have a good way
to compose things like format=flowed, and it's not clear to me how
that would work without some editor smarts.  I'm open to suggestions
(code would be better).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]