Opened 15 years ago

Last modified 7 years ago

#26 new defect

innfeed error 500 handler

Reported by: eagle Owned by: eagle
Priority: medium Milestone: 2.6.x
Component: innfeed Version:
Severity: normal Keywords: compliance
Cc:

Description

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.

Attachments (1)

innfeed-500-handler.patch (3.2 KB) - added by eagle 15 years ago.
Patch from 2000

Download all attachments as: .zip

Change History (9)

Changed 15 years ago by eagle

Attachment: innfeed-500-handler.patch added

Patch from 2000

comment:1 Changed 15 years ago by Julien ÉLIE

Keywords: compliance added

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.

comment:2 Changed 15 years ago by Julien ÉLIE

Priority: lowmedium

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.

comment:3 Changed 14 years ago by Julien ÉLIE

Milestone: 2.5.2
Severity: minornormal

comment:4 Changed 14 years ago by Julien ÉLIE

Milestone: 2.5.22.5.3

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.

comment:5 Changed 12 years ago by Julien ÉLIE

Milestone: 2.5.32.5.4

comment:6 Changed 10 years ago by Julien ÉLIE

Milestone: 2.5.42.5.5

comment:7 Changed 9 years ago by Julien ÉLIE

Milestone: 2.5.52.6.1

comment:8 Changed 7 years ago by Julien ÉLIE

Milestone: 2.6.12.6.x

Milestone renamed

Note: See TracTickets for help on using tickets.