Hallo Roelof,
On Mon, 17 Jul 2006 01:06:21 +0200GMT (17-7-2006, 1:06 , where I
live), you wrote:
RO Over at tbot we're having a thread threading badly as TB truncates
RO the References: header to a 1000 characters.
It appears that I've been to definite about the real culprit. TB
doesn't truncate the headers, but one of the mta's in between. However
this is what RFC2822 states on the maximum line length of header
fields:
,- [ 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
|
`-
,- [ 2.2.3. Long Header Fields ]
|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
|that wherever this standard allows for folding white space (not
|simply WSP characters), a CRLF may be inserted before any WSP. For
|example, the header field:
|
|Subject: This is a test
|
|can be represented as:
|
|Subject: This
| is a test
|
|Note: Though structured field bodies are defined in such a way that
|folding can take place between many of the lexical tokens (and even
|within some of the lexical tokens), folding SHOULD be limited to
|placing the CRLF at higher-level syntactic breaks. For instance, if
|a field body is defined as comma-separated values, it is recommended
|that folding occur after the comma separating the structured items in
|preference to other places where the field could be folded, even if
|it is allowed elsewhere.
|
|The process of moving from this folded multiple-line representation
|of a header field to its single line representation is called
|unfolding. Unfolding is accomplished by simply removing any CRLF
|that is immediately followed by WSP. Each header field should be
|treated in its unfolded form for further syntactic and semantic
|evaluation.
`-
RO Back with v2.12 the limit didn't exist either and TB even wrapped
RO the References header when replying, even when it was delivered as a
RO single line.
So I guess TB should get back to this behaviour of folding the
References: header even when it arrives unfolded.
--
Groetjes, Roelof
there are three things that come next, uh four...
The Bat! 3.81.10 Beta
Windows XP 5.1 Build 2600 Service Pack 2
1 pop3 account, server on LAN
OTFE enabled
P4 3GHz
2 GB RAM
pgpdubrNTaTJ0.pgp
Description: PGP signature
Current beta is 3.81.10 | 'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html
IMPORTANT: To register as a Beta tester, use this link first -
http://www.ritlabs.com/en/partners/testers/
