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)
Change History (9)
Changed 15 years ago by
Attachment: | innfeed-500-handler.patch added |
---|
comment:1 Changed 15 years ago by
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
Priority: | low → medium |
---|
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
Milestone: | → 2.5.2 |
---|---|
Severity: | minor → normal |
comment:4 Changed 14 years ago by
Milestone: | 2.5.2 → 2.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
Milestone: | 2.5.3 → 2.5.4 |
---|
comment:6 Changed 10 years ago by
Milestone: | 2.5.4 → 2.5.5 |
---|
comment:7 Changed 9 years ago by
Milestone: | 2.5.5 → 2.6.1 |
---|
Patch from 2000