1. Forum
  2. Usenet
  3. NEWS.SOFTWARE.NNTP

  • INN - What happens when a cancel is received prior to the cancelled art

    From Jesse Rehmer@21:1/5 to All on Tue Dec 12 05:01:35 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ray Banana@21:1/5 to All on Tue Dec 12 06:45:08 2023
    Thus spake Jesse Rehmer <[email protected]>

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jesse Rehmer@21:1/5 to Ray Banana on Sun Dec 17 15:10:34 2023
    On Dec 11, 2023 at 11:45:08 PM CST, "Ray Banana" <[email protected]> wrote:

    Thus spake Jesse Rehmer <[email protected]>

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ray Banana@21:1/5 to All on Sun Dec 17 17:23:51 2023
    Thus spake Jesse Rehmer <[email protected]>

    "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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=C3=89LIE?=@21:1/5 to All on Tue Dec 26 11:16:43 2023
    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. »

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)