Article rejection reason
Jeffrey M. Vinocur
Under "Sites sending bad articles", what qualifies something for the
Other column? That seems to be almost entirely what I get (U2 only,
three peers).
ObArgh: Why does vim keep eating my ^[ ?
ObFoo: So this isn't a place we need ObArghs, but oh well.
--
Jeffrey M. Vinocur
je...@litech.org
Russ Allbery
> Under "Sites sending bad articles", what qualifies something for the
> Other column? That seems to be almost entirely what I get (U2 only,
> three peers).
Stuff that doesn't fall into any of the other columns. :) I forget what
all goes in there; stuff like dates out of range, weird strings in the
article, lots of other stuff that shows up in the miscellaneous rejections
report too. I forget where the Perl filter rejections end up.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Jeffrey M. Vinocur
Russ Allbery <r...@stanford.edu> wrote:
>
>Stuff that doesn't fall into any of the other columns. :) I forget what
>all goes in there; stuff like dates out of range, weird strings in the
>article, lots of other stuff that shows up in the miscellaneous rejections
>report too. I forget where the Perl filter rejections end up.
That's odd...I'm not sure what would make so many things show up
there...I'll take it up with the peer in question, I guess.
(Err, what miscellaneous rejections report? Actually, I think I don't
have enough logging turned on...is there a default that I should've
changed and didn't?)
Russ Allbery
> That's odd...I'm not sure what would make so many things show up
> there...I'll take it up with the peer in question, I guess.
> (Err, what miscellaneous rejections report?
This one:
Miscellaneous innd statistics [Top 10]:
Event Number
Article posted in the future
news-out.nibble.net 142
sunqbc.risq.qc.ca 119
newsfeed.esat.net 69
diablo.cs.uofs.edu 39
feeder.via.net 32
TOTAL: 5 401
Bad Message-ID's offered
diablo.cs.uofs.edu 209
news-out.nibble.net 172
sunqbc.risq.qc.ca 137
feeder.via.net 71
newsfeed.esat.net 68
TOTAL: 5 657
Huge articles
sunqbc.risq.qc.ca 144
TOTAL: 1 144
Including strange strings
newsfeed.stanford.edu 3029
feeder.via.net 364
newsfeed.esat.net 281
news-out.nibble.net 102
newsfeed.fu-berlin.de 67
newsfeeds.nerdc.ufl.edu 4
sunqbc.risq.qc.ca 3
hsnx.callatg.com 3
unlnews.unl.edu 2
waltz.mi.linux.it 2
TOTAL: 10 3857
No colon-space in header
newsfeed.esat.net 8
TOTAL: 1 8
TOTAL: 5 5067
Although after peering at this some, it looks like the Perl filter
rejections get rolled into "other" and that's a big chunk of my rejections
(so my "other" category is pretty big). I think I may replace one of the
existing columns with filter rejections instead at some point; I think
they're more common than, say, line fuzz rejections.
> Actually, I think I don't have enough logging turned on...is there a
> default that I should've changed and didn't?)
No... as long as you're logging news.notice, you should have everything.
Russ Allbery
> So where is it that people are looking to see why a particular article
> was rejected? (Or are they not using INN?)
The news log. Although it doesn't log everything except in the latest
snapshots (it used to not log problems found by ARTclean).
Jeffrey M. Vinocur
Hmm...if I've got pretty clean feeds, I bet this section doesn't show up
at all.
>No... as long as you're logging news.notice, you should have everything.
So where is it that people are looking to see why a particular article
was rejected? (Or are they not using INN?)
--
Jeffrey M. Vinocur
je...@litech.org
Jeffrey M. Vinocur
>> was rejected? (Or are they not using INN?)
>
>snapshots (it used to not log problems found by ARTclean).
I'm getting no by-article rejection data in news.notice, just a
"connected" log entry and then a "closed" one, listing
accepted/rejected/refused.
Russ Allbery
> I'm getting no by-article rejection data in news.notice, just a
> "connected" log entry and then a "closed" one, listing
> accepted/rejected/refused.
It's in news, not news.notice.
Jeffrey M. Vinocur
Russ Allbery <r...@stanford.edu> wrote:
>Jeffrey M Vinocur <je...@tiamat.litech.org> writes:
>
>> I'm getting no by-article rejection data in news.notice, just a
>> "connected" log entry and then a "closed" one, listing
>> accepted/rejected/refused.
>
>It's in news, not news.notice.
Often when I look there's nothing there, which is why I ignored it.
I think a straight Usenet II feed from good peers causes very little
log activity.
However, I found my immediate problem...articles had been rejected
earlier[1] and inn was being too smart and remembering them[3].
Anyway, I'm (slowly) making progress towards figuring out what to do
-- it's very educational and kinda fun -- but it would be nice if I
could back out of some of the things I've tried.
Thus, my actual question is: are the entries in db/history[5] the
only thing preventing me from trying to feed a particular group
again after getting lots of rejections, and if I just delete those
lines do I get to try again? (My worry is about the db/history.foo
files; I'm not sure what they do.)
Hmm, this was going to be a short article. Whoops. I'm really not
in the mood to take it to news.software.nntp, although I probably
should.
[1] Several times, as I figured out what I was doing. Once because
I had neglected to update the active file, once because I
updated it wrong[2], and once because they were old and I hadn't
bumped up the expiration time[4].
[2] I can't decipher the manpage, do any of the fourth field options
allow articles to come in via IHAVE but not via POST? That'd be
nice.
[3] Is the benefit of remembertrash just a savings of cpu time, or
does it have a visible effect?
[4] Ok, now I'm more confused. I set the expiration times on the
new groups to never, and I'm still getting tooold rejections.
[5] I've got some human-readable entries from the u2 feed, and a
whole bunch of new hash entries that must be from what I've been
trying today. (It shouldn't be a problem if I delete too many
by accident, right?)
Russ Allbery
> However, I found my immediate problem...articles had been rejected
> earlier[1] and inn was being too smart and remembering them[3].
Barry has a patch for that that I need to go look at and integrate; it's
floating around in my mail somewhere.
> Thus, my actual question is: are the entries in db/history[5] the
> only thing preventing me from trying to feed a particular group
> again after getting lots of rejections,
Yup.
> and if I just delete those lines do I get to try again?
You need to run makedbz after modifying history and you don't want to do
this while INN is running (throttle it first). makehistory instead of
makedbz with older versions of INN.
> [1] Several times, as I figured out what I was doing. Once because
> I had neglected to update the active file, once because I
> updated it wrong[2], and once because they were old and I hadn't
> bumped up the expiration time[4].
> [2] I can't decipher the manpage, do any of the fourth field options
> allow articles to come in via IHAVE but not via POST? That'd be
> nice.
Yup. 'n'.
> [3] Is the benefit of remembertrash just a savings of cpu time, or
> does it have a visible effect?
Savings of network bandwidth more to the point. Particularly if you're
rejecting big binaries.
> [4] Ok, now I'm more confused. I set the expiration times on the
> new groups to never, and I'm still getting tooold rejections.
You have to fiddle with how old of Date headers that INN will tolerate; by
default, it won't accept articles older than fourteen days to prevent
loops.