Re: OT Length of Header-Lines?

[Karl Kleinpaste <karl@jprc.com>]

On the one hand, this is an utterly stupid question to have to answer.
Any "new" mail-serving program which imposes such severe line length
limits of that sort has, in the very first analysis, violated the
Robustness Principle.

RFC 1122, "Requirements for Hosts -- Communications Layers", p. 12:
________________

      1.2.2  Robustness Principle

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability [IP:1]:

                "Be liberal in what you accept, and
                 conservative in what you send"
________________

This bug (and that's what it is) appears to be the flip side of the
R.P., being so conservative as to be inoperable, and non-
interoperable.  This conservatism is horribly misplaced -- messages
with line sizes > 255 bytes are routine.  Did the authors of IMail not
do any robustness testing of their own, before inflicting this on the
world at large?  This is pretty much a first order, low-grade testing
criteria, after all: "Does our software handle `big things,'
generally?"  Did no one think to ask, "How much sense does a measly
little 255-byte length limitation make in this day of gigabit trunk
lines and gigabyte discs?"

That said, the only reference to these sorts of things in the RFCs
appears to be RFC 821, "SMTP", p. 42:
________________

      4.5.3.  SIZES

	 There are several objects that have required minimum maximum
	 sizes.  That is, every implementation must be able to receive
	 objects of at least these sizes, but must not send objects
	 larger than these sizes.

	  ****************************************************
	  *                                                  *
	  *  TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION  *
	  *  TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
	  *  OF THESE OBJECTS SHOULD BE USED.                *
	  *                                                  *
	  ****************************************************

	[...]

	    text line

	       The maximum total length of a text line including the
	       <CRLF> is 1000 characters (but not counting the leading
	       dot duplicated for transparency).
________________

Text emphasis and offset in original.  And that block of text is
repeated on the next page, for additional emphasis.  Observe that RFC
821 dates from 1982 -- fully 16 years ago -- when 1000 bytes could be
considered in some contexts to be a lot of space.  Is that true any
longer today?  Of course not.

Note that 821 demands acceptance of "at least these sizes."  Not "at
most," and not "if the software is feeling especially condescendingly
service-oriented today."  Just "at least these sizes."

RFCs 1122 & 1123 have no comment, as do the POP RFCs, from my brief
perusal.  No such document discusses the acceptability of truncation,
which is to say, it's not.

Length limits are Bad, nearly everywhere they are encountered.  They
may be needed in certain circumstances, but they should be avoided
whenever possible.  Anyone who is writing such software *today* ought
to be expected to be sufficiently aware of general habits on the net
in the first place, so as not to write ridiculously length-limited
code like that.

--karl