Arrgh! latest innfeed crashes like heck!

[Sven Paulus]

On 14.04., Barry Bouwsma wrote:
> > Another problem concerning innfeed came up on de.admin.news.misc some days
> > ago: Someone posted an article containing a Message-ID 494 characters long.
> > Now some NNTPRelay and Diablo peers rejected this Message-ID as being too
> > long with an 500 return code (= syntax error).
> Actually, that would have been a `400' response code in the case of
> NNTPRelay (which is where I noticed this problem).  I didn't notice
> what the response was for Diablo peers.

Oops, sorry, the problems with diablo were reported by someone else, I was
a little confused ... It's DNEWS which caused the 500 problems:

Apr 11 23:42:55 xxxxxxxx innfeed[13759]: yyyyyy:1 cxnsleep response unknown : 500 : 500 command too long
200 yyy.yy.yy.yy DNEWS Version 5.3e3, S0, posting OK

> I used to see this problem with truncated message IDs that would
> bounce around with a `400' error from NNTPRelay, and I think Diablo

Yes, you're right, NNTPrelay answers with 439 giving a truncated ID :(

> I think I'll figure out what the max message length of NNTPRelay and
> Diablo are, and add a sanity check on the length, because those responses

Son of 1036 limits the overall length of a Message-ID to 250 octets. innfeed
could just drop articles with ID which are longer, configurable per peer,
but this isn't a nice solution at all. Being more robust towards broken
peers is better. And before a Message-ID starts looping we should better
drop it ...

What I was thinking about: Is there a possibility that the remote site
shuffles the order of the replys of an CHECK command?

< CHECK <abc at def>
< CHECK <ghi at jkl>
< CHECK <mno at pqr>
> 23x <ghi at jkl>
> 43x <abc at def>
> 23x <mno at pqr>

If this isn't the case, we could just drop the _first_ article in the
take/check-queue if we receive an unknown reply (500 or 2xx or 4xx with
unknown ID) from the remote site.

> at any time.  I'd say the site on the other end needs to be fixed, but

Of course, this is the best solution.

> if it's possible to work around the most likely causes of these responses,
> innfeed should do that too.

Yes.

Sven