* OT Length of Header-Lines? @ 1998-10-29 20:13 Robert Epprecht 1998-10-29 21:06 ` Karl Kleinpaste 0 siblings, 1 reply; 5+ messages in thread From: Robert Epprecht @ 1998-10-29 20:13 UTC (permalink / raw) Cc: juerg.heim 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: OT Length of Header-Lines? 1998-10-29 20:13 OT Length of Header-Lines? Robert Epprecht @ 1998-10-29 21:06 ` Karl Kleinpaste 1998-10-30 8:24 ` Robert Epprecht 1998-10-30 16:44 ` Jason L Tibbitts III 0 siblings, 2 replies; 5+ messages in thread From: Karl Kleinpaste @ 1998-10-29 21:06 UTC (permalink / raw) Cc: juerg.heim 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: OT Length of Header-Lines? 1998-10-29 21:06 ` Karl Kleinpaste @ 1998-10-30 8:24 ` Robert Epprecht 1998-10-30 16:44 ` Jason L Tibbitts III 1 sibling, 0 replies; 5+ messages in thread From: Robert Epprecht @ 1998-10-30 8:24 UTC (permalink / raw) Cc: ding, juerg.heim 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: OT Length of Header-Lines? 1998-10-29 21:06 ` Karl Kleinpaste 1998-10-30 8:24 ` Robert Epprecht @ 1998-10-30 16:44 ` Jason L Tibbitts III 1998-10-30 18:20 ` Michael Welsh Duggan 1 sibling, 1 reply; 5+ messages in thread From: Jason L Tibbitts III @ 1998-10-30 16:44 UTC (permalink / raw) >>>>> "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< ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: OT Length of Header-Lines? 1998-10-30 16:44 ` Jason L Tibbitts III @ 1998-10-30 18:20 ` Michael Welsh Duggan 0 siblings, 0 replies; 5+ messages in thread From: Michael Welsh Duggan @ 1998-10-30 18:20 UTC (permalink / raw) 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) . ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1998-10-30 18:20 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-10-29 20:13 OT Length of Header-Lines? Robert Epprecht 1998-10-29 21:06 ` Karl Kleinpaste 1998-10-30 8:24 ` Robert Epprecht 1998-10-30 16:44 ` Jason L Tibbitts III 1998-10-30 18:20 ` Michael Welsh Duggan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).