Re: long message id as first reference

On Wednesday 19 December 2007 12:18:34 Martin Trautmann wrote:
> Hi all,
>
> what may happen when I reply to a message with a very long message-id?
>
> Yesterday I composed a posting such as
>
> Newsgroups: de.rec.heimwerken
> From: Martin Trautmann <[email protected]>
> Subject: Re: Elektronisches Zylinderschloß
> References:
>   <[email protected]>
>   <[email protected]>
>   <[email protected]>
>   <[email protected]> <[email protected]>
>   <[email protected]>
>   <[email protected]> <[email protected]>
>   <[email protected]> <[email protected]>
>   <[email protected]>
> Date: Tue, 18 Dec 2007 16:58:56 +0100
> User-Agent: slrn/0.9.8.1pl2.1 (Linux)
> Message-ID: <[email protected]>
>
>
> According to RFC 3977 a message-id may be up to 250 octets.

According to RFC 2822,
   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.

> Was it slrn which wrapped the message id to the next references line?

Yes, but it was wrong to do so. 

According to RFC 1036,
   Each header line consist of a keyword, a colon, a blank, and some
   additional information. [...] The Internet convention of continuation
   header lines (beginning with a blank or tab) is allowed.

And RFC 3977 states,
   NNTP allows a header line to be folded (by inserting a CRLF pair) before
   any space or TAB character. [...] Netnews articles are further required to
   have the header name, colon, and following space all on the first line;
   folding may only happen beyond that space.

slrn 0.9.8.1pl2 was folding the line *before* white space and thus also 
removing the "following white space" from the first line, both of which are 
contrary to RFC 3977, and was also failing to include "some additional 
information" after the "blank", which is contrary to RFC 1036.

Fortunately, slrn pre0.9.9 has fixed this bug. If you upgrade you should get a 
warning about the long line (which can be ignored), but the only lack of 
standard compliance will be that RFC 2822's recommendation that lines longer 
than 78 characters SHOULD be folded. This *recommendation* is over-ruled by 
the other standards' *requirements*.

> Is this valid? I think I had seen a posting recently which confirmed that
>
> keyword:[space]
>   [content]
>
> SHOULD be ok. But I do not remember where.

That's OK according to RFC 3977, but not according to RFC 1036, and in any 
case it's not what 0.9.8.1pl2 was doing.

> I was told about
> <news://news.aioe.org/[email protected]>
>
> which became complete garbage:

<...>

Ick. I suppose that's a result of an attempt by the server to change the order 
of headers, which led to nonsense because the headers were broken. Other 
servers have been reported to delete the broken References completely, which 
causes a different kind of nuisance.

Anyway, as I said above, the solution is to upgrade to the latest SVN version:
<http://sourceforge.net/svn/?group_id=7768>

Google Groups SHOULD NOT be generating these long header lines, in my opinion 
based on my interpretation of all the relevant standards, but there are 
plenty of other problems with GG, and I don't expect anything to change. 

-- 
PJR :-)

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace