innfeed error 500 handler

[eagle]

Sven Paulus wrote in 2000:

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). innfeed logged a cxnsleep message and requeued the article for resending it later. You surely will guess what follows? innfeed is happily trying to resend this article over and over again, until you force a shutdown of the innfeed process and dig the Message-ID out of the batch files ...

The real problem is, that innfeed has only _one_ return code handler for all commands, so you have to figure out, whether the 500 was in reply to an IHAVE, to a CHECK or to a TAKETHIS command.

My idea how a handler function for 500 replies could look like is this, but I haven't tested it yet (I'd have to setup a isolated test environment, I don't want to pollute the 'real' net with articles causing problems). But maybe who knows innfeed a little better than me could have a look on it and say if this makes sense.

[eagle]

Patch from 2000

[Julien ÉLIE]

Maybe innfeed should not try to propagate such messages (and innd should not have accepted them -- even after TAKETHIS) because the message-ID is not valid.

USEPRO states:

The msg-id MUST NOT be more than 250 octets in length.

NOTE: The length restriction ensures that systems that accept message identifiers as a parameter when referencing an article (e.g. [RFC3977]) can rely on a bounded length.

RFC 3977 states:

o A message-id MUST begin with "<", end with ">", and MUST NOT contain the latter except at the end.

o A message-id MUST be between 3 and 250 octets in length.

o A message-id MUST NOT contain octets other than printable US-ASCII characters.

[Julien ÉLIE]

Beware that these NNTPRelay and Diablo peers should have returned 501 (and not 500) because the base command is known. It was only a syntax error.

RFC 977 already stated that. And RFC 3977 currently states the same.

There are probably other return codes to catch, besides 500 and 501.

[Julien ÉLIE]

Also see the definition of a failed connect (should the sleepTimeout be reset in getModeResponse() when innfeed sends MODE STREAM and receives an unknown answer?).

More generally, innfeed should implement RFC 3977.

[Julien ÉLIE]

Milestone renamed