With the efforts being made to combat spam from Google Groups via NoCeMs, I
was wondering what INN does when it receives a cancel for an article that does
not exist on the spool?

I see reference in old Diablo documentation about configuring two feeds to
downstream INN servers, one to send cancels, and the second feed to send
everything else, but the second feed is delayed so that the cancels can be
processed before the cancelled articles arrive from the delayed feed.

Currently my production system is using tradspool, so articles are deleted
from the filesystem if cancelled, but when thinking about CNFS buffers, the
articles will not be removed and that leaves 'junk space' in the buffer. I am
thinking ahead for when I do make the switch to CNFS, if it might be
beneficial to accept a delay inbound if I can feed it news.lists.filters and
the NoCeMs get processed before the spam is received, but I'm not entirely
sure what INN does when it receives a cancel for an article that does not
exist in the history file.

Thus spake Jesse Rehmer <jesse.rehmer@blueworldhosting.com>

> the NoCeMs get processed before the spam is received, but I'm not entirely
> sure what INN does when it receives a cancel for an article that does not
> exist in the history file.

"ctlinnd cancel" will add an entry to the history file listing the storage
token as /dev/null. If a spam article arrives after the NoCeM message
for the same article, it is rejected as duplicate. I'm running separate
transit and reader servers (the Google filter is running on the transit
server) and had the opportunity to verify this behaviour using INN 2.8
Current and CNFS storage.

--
Пу́тін — хуйло́
http://www.eternal-september.org

On Dec 11, 2023 at 11:45:08 PM CST, "Ray Banana" <rayban@raybanana.net> wrote:

> Thus spake Jesse Rehmer <jesse.rehmer@blueworldhosting.com>
>
>> the NoCeMs get processed before the spam is received, but I'm not entirely
>> sure what INN does when it receives a cancel for an article that does not
>> exist in the history file.
>
> "ctlinnd cancel" will add an entry to the history file listing the storage
> token as /dev/null. If a spam article arrives after the NoCeM message
> for the same article, it is rejected as duplicate. I'm running separate
> transit and reader servers (the Google filter is running on the transit
> server) and had the opportunity to verify this behaviour using INN 2.8
> Current and CNFS storage.

Does the null storage token stay in the history database forever, or is it
eventually removed with expire operations after the remember time?

Thus spake Jesse Rehmer <jesse.rehmer@blueworldhosting.com>

>> "ctlinnd cancel" will add an entry to the history file listing the storage
>> token as /dev/null. If a spam article arrives after the NoCeM message
>> for the same article, it is rejected as duplicate. I'm running separate
>> transit and reader servers (the Google filter is running on the transit
>> server) and had the opportunity to verify this behaviour using INN 2.8
>> Current and CNFS storage.
> Does the null storage token stay in the history database forever, or is it
> eventually removed with expire operations after the remember time?

The setting for /remember/: in expire.ctl applies to self-expiring
storage like CNFS that are no longer present in the spool.

--
Пу́тін — хуйло́
https://www.eternal-september.org

Hi Jesse,

> I see reference in old Diablo documentation about configuring two feeds to
> downstream INN servers, one to send cancels, and the second feed to send
> everything else, but the second feed is delayed so that the cancels can be
> processed before the cancelled articles arrive from the delayed feed.

Interesting.
INN has a "delayer" script in the contrib directory, and may be used to
achieve that. For instance to send with a delay of 10 seconds all the
articles except for cancels and NoCeM notices:

news.server.com/news.server.com\
:!*,news.lists.filters,control.cancel\
:Tm:innfeed!

news.server.com-delayed/news.server.com\
:*,!news.lists.filters,!control.cancel\
:Tm:innfeed-delayed!!

innfeed!\
:!*\
:Tc,Wnm*:/usr/local/news/bin/innfeed

innfeed-delayed!\
:!*\
:Tc,Wnm*:/usr/local/news/bin/delayer 10 \
/usr/local/news/bin/innfeed -c innfeed-delayed.conf

A news admin may also add a frontal server in his architecture, with a
small CNFS buffer, and delay himself the articles from all his peers
before integrating them into a second instance of his server.

(Articles may be directly fed without delay to other peers by the
frontal server. Only the internal feed is delayed.)

--
Julien ÉLIE

« Medicorum nutrix est intemperantia. »