• ? Is this a valid example of a peering configuration ? And other questions ?

    From G.K.@g@k.invalid to news.admin.peering,news.software.nntp on Sat Aug 2 01:26:32 2025
    From Newsgroup: news.software.nntp


    I am trying to absorb all the documentation for all the moving parts of INN2. RTFM is no good without solid examples and pointers from experience. This quest is onerous! Help me wrap my mind around this.

    My node is peer-1.net. The remote is peer-2.net.

    ```
    peer news.peer-1.net {
    type feed
    hostname news.peer-1.net
    port 119
    send comp.*:all,news.*:all,sci.*:all,alt.test
    receive comp.*,news.*,sci.*,alt.test
    allowed-groups comp.*,news.*,sci.*,alt.test
    max-crosspost 3
    max-connections 5
    }
    ```

    My purpose is as follows. I expect that the remote peer operator adds this to incoming.conf. Later if I wanted to add some local hierarchy groups, this would ensure that the remote peer is not allowing me to send them over (hopefully) and my config below would also prevent my peer from trying to send them over.

    Then I would add the following to my incoming.conf with the expectation that my peer should receive the three hierarchies [comp.*, news.*, sci.*] and the single group [alt.test] and reject articles cross-posted to more than 3 groups ... and my peer should reciprocate the same original rules when sending to the remote.

    ```
    peer news.peer-2.net {
    type feed
    hostname news.peer-2.net
    port 119
    send comp.*:all,news.*:all,sci.*:all,alt.test
    receive comp.*,news.*,sci.*,alt.test
    allowed-groups comp.*,news.*,sci.*,alt.test
    max-crosspost 3
    max-connections 5
    }
    ```

    Of course, many peers operators would have different preferences for what my peer should send to theirs, so my local config would necessarily be different than the example. But let's stick to this mirroring example. Is this valid as shown herein? Would it do what I think it should, which is for my peer to only receive the three hierarchies [comp.*, news.*, sci.*] and the single group [alt.test] and reject articles cross-posted to more than 3 groups, and vice-versa for the remote peer? If not, why not? If not, what should I change? Is there a better way to do it?

    Also, I see many peers have the tokens, 'Aj' and 'Tm' in their preferred peer configurations for the 'newsfeed' file, often next to the max article size sign ('<'). What exactly do those tokens instruct INN2 to do? I presume 'Aj' means, 'automatically junk' or something like that, but what exactly does that entail? Then I presume that 'Tm' has something to do with time or timeout. What exactly do they cause to happen under the hood?

    For example, I found this 'newsfeeds' file config online:

    ```
    usenet.blueworldhosting.com\
    :*,!unidata.*,!control.*,!junk/!local\
    :Aj,Tm,<1000000:innfeed!
    ```

    I presume this means to reject messages for group names containing starting tokens, 'unidata', 'control', 'junk', and 'local'. But then what are the tokens, 'Aj', 'Tm', and '<1000000:innfeed!' supposed to be doing? Are articles less than 1000000 bytes being sent to 'innfeed'? What is 'innfeed' and what does it do? How do the 'Aj' and 'Tm' tokens modify this token? What effect would these tokens have on my local server if peered with this other server?

    Then there is this innfeed.conf from the same source:

    ```
    peer usenet.blueworldhosting.com {
    ip-name: usenet.blueworldhosting.com
    }
    ```

    The syntax seems pretty self-explanatory. So for the remote peer connecting to my peer I presume the remote peer should have this within its innfeed.conf:

    ```
    peer news.peer-1.net {
    ip-name: news.peer-1.net
    }
    ```

    And I presume the parameter 'ip-name' causes INN2 to resolve the domain name to its IP address then connect. Or is something else going on there?

    I have to ask a lot of questions to get up to speed on how this system works because there is no way I will ever have time to comb through the source code. I would be here a month with caffeine psychosis trying to figure it out that way.

    What else should I be asking and inspecting to wrap my mind around this for my purpose? What am I missing?

    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Julien_=C3=89LIE?=@iulius@nom-de-mon-site.com.invalid to news.admin.peering,news.software.nntp on Sat Aug 2 09:40:44 2025
    From Newsgroup: news.software.nntp

    Hi G.K.,

    RTFM is no good without solid examples and pointers from experience.

    To set up peering, the 3 relevant files to parameterize are newsfeeds, incoming.cong and innfeed.conf:
    https://www.eyrie.org/~eagle/software/inn/docs/newsfeeds.html
    https://www.eyrie.org/~eagle/software/inn/docs/incoming.conf.html
    https://www.eyrie.org/~eagle/software/inn/docs/innfeed.conf.html

    I once added a section at the beginning of their documentation, "In a Nutshell", with straight-forward examples but it seems from your message
    it is still not enough...


    My node is peer-1.net. The remote is peer-2.net.

    ```
    peer news.peer-1.net {
    type feed
    hostname news.peer-1.net
    port 119
    send comp.*:all,news.*:all,sci.*:all,alt.test
    receive comp.*,news.*,sci.*,alt.test
    allowed-groups comp.*,news.*,sci.*,alt.test
    max-crosspost 3
    max-connections 5
    }
    ```

    My purpose is as follows. I expect that the remote peer operator adds this to incoming.conf.

    The above peer block is not a valid syntax for incoming.conf (at least
    for INN 2; it may be a syntax for another software).


    Also, I see many peers have the tokens, 'Aj' and 'Tm' in their
    preferred peer configurations for the 'newsfeed' file, often next to
    the max article size sign ('<'). What exactly do those tokens instruct
    INN2 to do? I presume 'Aj' means, 'automatically junk' or something
    like that, but what exactly does that entail?

    """
    Aj
    Propagate articles according to their Newsgroups header field. This is
    only useful when wanttrash is set to true in inn.conf. With that
    variable set, articles accepted and filed in junk (due to wanttrash) are
    fed to peers based on their subscription pattern applied to the
    Newsgroups header field as though they were accepted and all those
    groups were locally carried. Otherwise, they are propagated to sites
    that receive the junk newsgroup.
    """


    Then I presume that 'Tm' has something to do with time or timeout. What exactly do they cause to happen under the hood?

    """
    T type
    This flag specifies the type of feed for this site; type should be a
    letter chosen from the following set:

    c Channel
    f File
    l Log entry only
    m Funnel (multiple entries feed into one)
    p Program
    x Exploder
    """

    As there are multiple entries in newsfeeds to the innfeed program, "Tm"
    is used.


    For example, I found this 'newsfeeds' file config online:

    ```
    usenet.blueworldhosting.com\
    :*,!unidata.*,!control.*,!junk/!local\
    :Aj,Tm,<1000000:innfeed!
    ```

    I presume this means to reject messages for group names containing starting tokens, 'unidata', 'control', 'junk', and 'local'.

    This entry means the peer will be fed all articles (*) except the ones
    only posted to groups whose names begin with "unidata." or "control.",
    or whose name is "junk", and which do not have "local" in their
    Distribution header field.

    Note that the "only posted" is important, as an article crossposted to "unidata.test,news.software.nntp" will still be propagated. Otherwise, another syntax is used to prevent that (@unidata.* instead of !unidata.*).

    "/" (and not ",") after "!junk" means the rest of the pattern is for distributions, meant to restrict the propagation of articles.


    But then what are the tokens, 'Aj', 'Tm', and '<1000000:innfeed!' supposed to be doing? Are articles less than 1000000 bytes being sent to 'innfeed'?

    Exactly.
    There's an "innfeed!" entry afterwards in the newsfeeds configuration file.


    What is 'innfeed' and what does it do?

    It is the program which sends articles to remote peers.


    ```
    peer news.peer-1.net {
    ip-name: news.peer-1.net
    }
    ```

    And I presume the parameter 'ip-name' causes INN2 to resolve the domain name to its IP address then connect.

    Yes.
    BTW, this is the configuration (innfeed.conf) for the innfeed program.
    --
    Julien |eLIE

    -2-aSois sage, || ma douleur, et tiens-toi plus tranquille.-a-+ (Charles
    Baudelaire)

    --- Synchronet 3.21a-Linux NewsLink 1.2