cant store article: bogus Xref: header in INN 2.5 ?

[Julien ÉLIE]

Hi Matija,

> It seems I have managed to reproduce the problem -- if I send to
> newsfeed.carnet.hr article with Xref containing double spaces and
> some unrelated host, like:
> 
> Message-ID: <slrnj5uvtq.3pot2.mnalis-news at newsfeed.carnet.hr>
> Xref:  news.trigofacile.com misc.test:9
> 
> it seems the newsfeed running 2.4.6-snapshot-20090119 will update the
> header with its own data, *but* leave the two spaces after Xref:
> 
> news at newsfeed:~$ sm `grephistory '<slrnj5uvtq.3pot2.mnalis-news at newsfeed.carnet.hr>'` | grep Xref
> Xref:  newsfeed.CARNet.hr misc.test:2212835
> 
> and then such message will be propagated to news2 running 2.5.2-2~squeeze1, and it
> will promptly break.

I do not manage to reproduce the issue with latest STABLE INN 2.5:

innd
----

IHAVE <ITv0a$3test at news.trigofacile.com3>
335 Send it
Path: pouet!test
From: =?ISO-8859-15?Q?Julien_=C9LIE?= <iulius at nom-de-mon-site.com.invalid>
Newsgroups: trigofacile.test
Subject: test
Date: Wed, 30 Aug 2011 16:19:01 +0200 (CEST)
Message-ID: <ITv0a$3test at news.trigofacile.com3>
Xref:      plop.plop.test    trigofacile.test:510

plop
.
235 Article transferred OK


nnrpd
-----

ARTICLE <ITv0a$3test at news.trigofacile.com3>
220 0 <ITv0a$3test at news.trigofacile.coz3> article
Path: news.trigofacile.com!pouet!test
From: =?ISO-8859-15?Q?Julien_=C9LIE?= <iulius at nom-de-mon-site.com.invalid>
Newsgroups: trigofacile.test
Subject: test
Date: Wed, 30 Aug 2011 16:19:01 +0200 (CEST)
Message-ID: <ITv0a$3test at news.trigofacile.com3>
Xref: news.trigofacile.com trigofacile.test:511

plop
.




> I think that mistery should be solved above...
> 
> As how to fix inn 2.5, I'm in favour of Russ idea of being more lax
> and allowing multiple spaces (but maybe emiting only one when it is
> rewritten).

If the above example is not what you see with INN 2.4.6, then it means that
the issue of multiple spaces on Xref: generation is solved.
I bet it was solved when how innd handles header fields has been changed.
We previously (INN 2.4) marked the start of a header field value after
all leading whitespaces; now (INN 2.5), a header field value begins after
the first leading space after the comma.




> Alternatively, reject such articles if we must (but if RFC allow it
> as it seems to be the case, I'd rather accept them), but just reject
> such articles instead of throttling the server.

We should be laxer.  Especially when the syntax is valid, as Russ and you
are highlighting that fact.



So, hmm...  Maybe you could upgrade your newsfeed server to 2.5.2-2~squeeze1;
I bet it will directly solve the issue for your slave server :-)

Otherwise, you could patch your slave server with a pending patch I will post
in my next message.

-- 
Julien ÉLIE

« Un voyage de mille lieues commence toujours par un premier pas. »
  (Lao Zi)