OT Length of Header-Lines?

OT Length of Header-Lines?

[Robert Epprecht]

Hello.

I'm getting my mail through a new mailserver (IMail 4.03b).
The headers get truncated after 255 bytes, which can't be 
The Right Thing (tm). So after a long 'References: '-line Gnus thinks 
that the other lines belong to the text of the message and shows the 
rest of the 'References: '-line (and any following headers) as article.

To clarify the situation with my ISP I want to know how a mailserver
should treat long header lines: 
How long are they allowed to get?
After how many bytes is it ok to truncate? 
Where is that regulated?

Robert Epprecht

Re: OT Length of Header-Lines?

[Karl Kleinpaste]

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

Re: OT Length of Header-Lines?

[Robert Epprecht]

Karl Kleinpaste <karl@jprc.com> writes:

> On the one hand, this is an utterly stupid question to have to answer.
Yes I know ;-)
but thank you any way for the answer!

(BTW I asked the question being too tired (should never do this ...)
 and made a mistake: of course the long lines are not truncated, but
 broken in several lines <=255 bytes, which IMHO doesn't make too much
 difference in this case)

Robert Epprecht

Re: OT Length of Header-Lines?

[Jason L Tibbitts III]

>>>>> "KK" == Karl Kleinpaste <karl@jprc.com> writes:

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

I'll add for funnies that, as the owner of this list, I see bunches of fun
bounces due to this.  Folks at cs.cmu.edu, what crappy mailer are you
running there that _bounces_ mail if a header is over 510 characters?

It's off topic, but I'll also add that I get a lot of bounces doe to
non-ASCII characters in the headers.  Yes, my mailing list manager should
encode them as it sees them (though what character set to use is a mystery)
but whatever is generating them (which is probably Gnus) shouldn't be doing
so.  The incidence of this has gone up with the advent of pgnus.

 - J<

Re: OT Length of Header-Lines?

[Michael Welsh Duggan]

Jason L Tibbitts III <tibbs@hpc.uh.edu> writes:

> >>>>> "KK" == Karl Kleinpaste <karl@jprc.com> writes:
> 
> KK> On the one hand, this is an utterly stupid question to have to
> KK> answer. Any "new" mail-serving program which imposes such severe line
> KK> length limits of that sort has, in the very first analysis, violated
> KK> the Robustness Principle.
> 
> I'll add for funnies that, as the owner of this list, I see bunches of fun
> bounces due to this.  Folks at cs.cmu.edu, what crappy mailer are you
> running there that _bounces_ mail if a header is over 510 characters?

I asked around about this, and this is the answer I got:

: The answer, of course, is "one that we invented ourselves"

A second response replied:

: the answer is most definitely NOT 'one we invented ourselves' 
: the answer is MMDF...

I'll see if I can't get facilities to look into it again.

-- 
Michael Duggan
(md5i@cs.cmu.edu)
.