On Mon, 27 Mar 2006 13:51:38 EST, "Gartner, James" said:
> 
> Does anyone know the max length of the Subject: line allowed through the
> listserv (and any other mail systems)?
> I've looked through the RFC 822, but I didn't see any max number
> indicated.

You can't find it in RFC822 because RFC822 was buggy and didn't actually
say anything about the limit (although it *did* contain a description of
using 'folding white space' to work around the limit, whatever it might
be, in section 3.1.1.

RFC2822 addressed the lack of clarity on this basic point:

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.

It then turns right around and section 2.2.3 specifically says that a header
line can be "folded" to bypass the 998 limit:

   Each header field is logically a single line of characters comprising
   the field name, the colon, and the field body.  For convenience
   however, and to deal with the 998/78 character limitations per line,
   the field body portion of a header field can be split into a multiple
   line representation; this is called "folding".  The general rule is

In other words, any implementation that doesn't allow for the fact that
a header line can be over 998 octets(*) long after unfolding is buggy,
pure and simple.

(*) octets - originally used in documentation because a number of machines on
the early internet were 36-bit boxes, where fitting 6 six-bit, 5 seven-bit,
4 9-bit bytes, or even 3 12-bit bytes (lots of bucky-bits there. ;) into a
native word were common usages.  Then the world standardized on 8-bit bytes
and 36-bit boxes disappeared from memory of most.  Now with things like
UTF-8 on the loose, the distinction between octets and characters has once
again become important....