From julien at trigofacile.com  Tue Mar 22 21:32:56 2022
From: julien at trigofacile.com (=?UTF-8?Q?Julien_=c3=89LIE?=)
Date: Tue, 22 Mar 2022 22:32:56 +0100
Subject: Improving HTML status for innfeed and innd
Message-ID: <9312dbfa-a57f-5226-ca91-228f1865952d@trigofacile.com>

Hi all,

It has recently been asked in a French newsgroup the possibility to add 
a link to an external web page for feeds in HTML status.

Examples of innfeed and innd status:
   http://pasdenom.info/usenet/innfeed.status
   http://pasdenom.info/usenet/inn_status.html

That is to say, instead of:

nntp.alphanet.ch
  ip address: 193.72.186.6
     seconds: 1127           duplicates: 0     max allowed cxns: 1
     offered: 142         uw newsgroups: 0          active cxns: 1

having:

nntp.alphanet.ch
<a href="xxxxx">Usenet reports</a>
  ip address: 193.72.186.6
     seconds: 1127           duplicates: 0     max allowed cxns: 1
     offered: 142         uw newsgroups: 0          active cxns: 1



Do you think it worthwhile adding?

Any other idea of improvements to HTML reports?



I would suggest a new "html-comment" parameter in both innfeed.conf and 
incoming.conf, that would just be printed as-is below the name of the 
feed.  This way, anything could be added (text, link...).

No change in text-only status (there's currently no need for a similar 
feature, but if you feel it should be implemented too, please tell).

-- 
Julien ?LIE

??Tous les chemins m?nent ? rame??? (Moul?fix)

From julien at trigofacile.com  Tue Mar 22 21:39:20 2022
From: julien at trigofacile.com (=?UTF-8?Q?Julien_=c3=89LIE?=)
Date: Tue, 22 Mar 2022 22:39:20 +0100
Subject: Disabling XBATCH by default in innd
Message-ID: <85888527-b53d-2e11-25a0-e236cfb08ed6@trigofacile.com>

Hi all,

For users of CURRENT snapshots (main branch for upcoming 2.7.0 release), 
innd no longer accepts XBATCH commands by default.  A new "noxbatch" 
parameter has been added in incoming.conf, that should be set to false 
for remote peers with which you're using XBATCH.  (This may be very rare 
nowadays...)

-- 
Julien ?LIE

??S?me du bonheur dans le champ du voisin, tu seras surpris de constater
   ce que le vent fera produire au tien.?? (Juliette Saint Gelais)

From eagle at eyrie.org  Tue Mar 22 22:24:23 2022
From: eagle at eyrie.org (Russ Allbery)
Date: Tue, 22 Mar 2022 15:24:23 -0700
Subject: Disabling XBATCH by default in innd
In-Reply-To: <85888527-b53d-2e11-25a0-e236cfb08ed6@trigofacile.com> ("Julien
 =?utf-8?Q?=C3=89LIE=22's?= message of "Tue, 22 Mar 2022 22:39:20 +0100")
References: <85888527-b53d-2e11-25a0-e236cfb08ed6@trigofacile.com>
Message-ID: <87k0cltylk.fsf@hope.eyrie.org>

Julien ?LIE <julien at trigofacile.com> writes:

> For users of CURRENT snapshots (main branch for upcoming 2.7.0 release),
> innd no longer accepts XBATCH commands by default.  A new "noxbatch"
> parameter has been added in incoming.conf, that should be set to false
> for remote peers with which you're using XBATCH.  (This may be very rare
> nowadays...)

I wonder if it would be worth avoiding the double negative.  In other
words, introduce a new parameter "xbatch" with a default of "false" that
you set to "true" if you want to allow XBATCH access.

(I know INN has a few double negatives in configuration already, but they
tend to confuse people so it may be worth avoiding adding new ones.)

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

From julien at trigofacile.com  Wed Mar 23 17:10:32 2022
From: julien at trigofacile.com (=?UTF-8?Q?Julien_=c3=89LIE?=)
Date: Wed, 23 Mar 2022 18:10:32 +0100
Subject: Disabling XBATCH by default in innd
In-Reply-To: <87k0cltylk.fsf@hope.eyrie.org>
References: <85888527-b53d-2e11-25a0-e236cfb08ed6@trigofacile.com>
 <87k0cltylk.fsf@hope.eyrie.org>
Message-ID: <56266172-afdd-6a2e-cc77-90f81358ec9f@trigofacile.com>

Hi Russ,

>> For users of CURRENT snapshots (main branch for upcoming 2.7.0 release),
>> innd no longer accepts XBATCH commands by default.  A new "noxbatch"
>> parameter has been added in incoming.conf, that should be set to false
>> for remote peers with which you're using XBATCH.  (This may be very rare
>> nowadays...)
> 
> I wonder if it would be worth avoiding the double negative.  In other
> words, introduce a new parameter "xbatch" with a default of "false" that
> you set to "true" if you want to allow XBATCH access.
> 
> (I know INN has a few double negatives in configuration already, but they
> tend to confuse people so it may be worth avoiding adding new ones.)

Yes, that's exactly why I chose "noxbatch" as we already have 2 double 
negatives in incoming.conf.
I'm fine with naming it "xbatch" instead.

Maye we could rename "nolist" and "noresendid" to "list" and "resendit" 
in the major 2.7.0 release?
innupgrade can do the change.
This way, we'll get rid of all double negatives in incoming.conf.

We could also remove "comment" and "email" parameters which are unused 
in the code (I've checked), just mentioned "marked as reserved for 
future use" in documentation.

-- 
Julien ?LIE

??Ce que j'aime chez vous, c'est que vous savez jusqu'o? on va trop
   loin.?? (Cocteau)

From eagle at eyrie.org  Wed Mar 23 17:54:04 2022
From: eagle at eyrie.org (Russ Allbery)
Date: Wed, 23 Mar 2022 10:54:04 -0700
Subject: Disabling XBATCH by default in innd
In-Reply-To: <56266172-afdd-6a2e-cc77-90f81358ec9f@trigofacile.com> ("Julien
 =?utf-8?Q?=C3=89LIE=22's?= message of "Wed, 23 Mar 2022 18:10:32 +0100")
References: <85888527-b53d-2e11-25a0-e236cfb08ed6@trigofacile.com>
 <87k0cltylk.fsf@hope.eyrie.org>
 <56266172-afdd-6a2e-cc77-90f81358ec9f@trigofacile.com>
Message-ID: <87h77o8shv.fsf@hope.eyrie.org>

Julien ?LIE <julien at trigofacile.com> writes:

> Maye we could rename "nolist" and "noresendid" to "list" and "resendit"
> in the major 2.7.0 release?  innupgrade can do the change.  This way,
> we'll get rid of all double negatives in incoming.conf.

I know it's always disruptive to change things like this, but personally
I'd lean in favor of this.  What do other folks think?

> We could also remove "comment" and "email" parameters which are unused
> in the code (I've checked), just mentioned "marked as reserved for
> future use" in documentation.

"comment" is, IIRC, left over from a desire to make the configuration file
readable and writable by code without losing information.  That work was
never complete, and at this point I think if we were going to pursue this
again, we'd use a different format like YAML.  (The Python ruamel.yaml
module supports reading and writing YAML while preserving comments and
order.)  I'm in favor of dropping this.  Maybe innupgrade could convert
any that it finds to actual comments?

"email" I'm a bit more worried about since it's possible that people have
used that field as documentation to record the contact email address of a
peer.  I have no idea if anyone has done that or not, but keeping the
field is also fairly cheap, so I'm not sure if it's worth the potential
disruption.  Although maybe there too innupgrade could work some magic.

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

From julien at trigofacile.com  Wed Mar 23 18:14:26 2022
From: julien at trigofacile.com (=?UTF-8?Q?Julien_=c3=89LIE?=)
Date: Wed, 23 Mar 2022 19:14:26 +0100
Subject: Disabling XBATCH by default in innd
In-Reply-To: <87h77o8shv.fsf@hope.eyrie.org>
References: <85888527-b53d-2e11-25a0-e236cfb08ed6@trigofacile.com>
 <87k0cltylk.fsf@hope.eyrie.org>
 <56266172-afdd-6a2e-cc77-90f81358ec9f@trigofacile.com>
 <87h77o8shv.fsf@hope.eyrie.org>
Message-ID: <e6fb3c0d-12c9-dd01-0015-31ffe54eed7a@trigofacile.com>


Hi Russ,

>> Maye we could rename "nolist" and "noresendid" to "list" and "resendid"
>> in the major 2.7.0 release?  innupgrade can do the change.  This way,
>> we'll get rid of all double negatives in incoming.conf.
> 
> I know it's always disruptive to change things like this, but personally
> I'd lean in favor of this.  What do other folks think?

Let's wait for other opinions then.


>> We could also remove "comment" and "email" parameters which are unused
>> in the code (I've checked), just mentioned "marked as reserved for
>> future use" in documentation.
> 
> "comment" is, IIRC, left over from a desire to make the configuration file
> readable and writable by code without losing information.  That work was
> never complete, and at this point I think if we were going to pursue this
> again, we'd use a different format like YAML.  (The Python ruamel.yaml
> module supports reading and writing YAML while preserving comments and
> order.)  I'm in favor of dropping this.  Maybe innupgrade could convert
> any that it finds to actual comments?

Yes, I was meaning to drop code parsing for "comment" and "email", and 
innupgrade would just comment the lines (and not remove them).


> "email" I'm a bit more worried about since it's possible that people have
> used that field as documentation to record the contact email address of a
> peer.  I have no idea if anyone has done that or not, but keeping the
> field is also fairly cheap, so I'm not sure if it's worth the potential
> disruption.  Although maybe there too innupgrade could work some magic.

It would become commented in incoming.conf:
#email: "newsmaster at server.com"

-- 
Julien ?LIE

??Perl programming is an *empirical* science.?? (Larry Wall)

From eagle at eyrie.org  Wed Mar 23 18:21:37 2022
From: eagle at eyrie.org (Russ Allbery)
Date: Wed, 23 Mar 2022 11:21:37 -0700
Subject: Disabling XBATCH by default in innd
In-Reply-To: <e6fb3c0d-12c9-dd01-0015-31ffe54eed7a@trigofacile.com> ("Julien
 =?utf-8?Q?=C3=89LIE=22's?= message of "Wed, 23 Mar 2022 19:14:26 +0100")
References: <85888527-b53d-2e11-25a0-e236cfb08ed6@trigofacile.com>
 <87k0cltylk.fsf@hope.eyrie.org>
 <56266172-afdd-6a2e-cc77-90f81358ec9f@trigofacile.com>
 <87h77o8shv.fsf@hope.eyrie.org>
 <e6fb3c0d-12c9-dd01-0015-31ffe54eed7a@trigofacile.com>
Message-ID: <878rt08r7y.fsf@hope.eyrie.org>

Julien ?LIE <julien at trigofacile.com> writes:

> It would become commented in incoming.conf:
> #email: "newsmaster at server.com"

Oh, that's a great idea that for some reason I didn't think of.  I'm in
favor of doing that.

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

From kempe at lysator.liu.se  Fri Mar 25 16:52:12 2022
From: kempe at lysator.liu.se (Andreas Kempe)
Date: Fri, 25 Mar 2022 17:52:12 +0100
Subject: nnrpd: adding blacklistd support
Message-ID: <Yj3zPAuMR2LApcfc@shipon.lysator.liu.se>

Hello,

FreeBSD ships the software blacklistd, originally from NetBSD, that
allows blocking brute force attacks using the firewall. I've written a
small patch running on Lysator's news server adding support to nnrpd
for automatic blocking.

I'm writing this to probe whether there is any interest in having the
patch upstreamed. In its current form, the blacklist code is
unconditionally added but can of course be put behind an option to the
configure script or a FreeBSD define of some kind.

See the attached file for the patch.

Cordially,
Andreas Kempe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-nnrpd-add-blacklistd-support.patch
Type: text/x-diff
Size: 4905 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/inn-workers/attachments/20220325/32e3b374/attachment.patch>

From julien at trigofacile.com  Sun Mar 27 21:49:15 2022
From: julien at trigofacile.com (=?UTF-8?Q?Julien_=c3=89LIE?=)
Date: Sun, 27 Mar 2022 23:49:15 +0200
Subject: nnrpd: adding blacklistd support
In-Reply-To: <Yj3zPAuMR2LApcfc@shipon.lysator.liu.se>
References: <Yj3zPAuMR2LApcfc@shipon.lysator.liu.se>
Message-ID: <afe744b2-9e79-5dae-e72c-02119c9b69d2@trigofacile.com>

Hi Andreas,

> FreeBSD ships the software blacklistd, originally from NetBSD, that
> allows blocking brute force attacks using the firewall. I've written a
> small patch running on Lysator's news server adding support to nnrpd
> for automatic blocking.
> 
> I'm writing this to probe whether there is any interest in having the
> patch upstreamed. In its current form, the blacklist code is
> unconditionally added but can of course be put behind an option to the
> configure script or a FreeBSD define of some kind.
> 
> See the attached file for the patch.

Thanks for the patch.  I've had a look, and it seems that the 
integration of blacklistd is pretty straight-forward.
I think it deserves being integrated into INN, with a proper 
--with-blacklistd Autoconf probe (instead of an error if blacklistd is 
not found).  I'll have a look.  As I do not run FreeBSD myself, it would 
be great if you could somehow test it.

-- 
Julien ?LIE

??L'?ternit?, c'est long, surtout vers la fin.?? (Woody Allen)

From kempe at lysator.liu.se  Mon Mar 28 14:26:14 2022
From: kempe at lysator.liu.se (Andreas Kempe)
Date: Mon, 28 Mar 2022 16:26:14 +0200
Subject: nnrpd: adding blacklistd support
In-Reply-To: <afe744b2-9e79-5dae-e72c-02119c9b69d2@trigofacile.com>
References: <Yj3zPAuMR2LApcfc@shipon.lysator.liu.se>
 <afe744b2-9e79-5dae-e72c-02119c9b69d2@trigofacile.com>
Message-ID: <YkHFhut2tg/G0kit@shipon.lysator.liu.se>

Hello Julien,

On Sun, Mar 27, 2022 at 11:49:15PM +0200, Julien ?LIE wrote:
> Hi Andreas,
> 
> > FreeBSD ships the software blacklistd, originally from NetBSD, that
> > allows blocking brute force attacks using the firewall. I've written a
> > small patch running on Lysator's news server adding support to nnrpd
> > for automatic blocking.
> > 
> > I'm writing this to probe whether there is any interest in having the
> > patch upstreamed. In its current form, the blacklist code is
> > unconditionally added but can of course be put behind an option to the
> > configure script or a FreeBSD define of some kind.
> > 
> > See the attached file for the patch.
> 
> Thanks for the patch.  I've had a look, and it seems that the 
> integration of blacklistd is pretty straight-forward.
> I think it deserves being integrated into INN, with a proper 
> --with-blacklistd Autoconf probe (instead of an error if blacklistd is 
> not found). 

Adding it as --with-blacklistd sounds like the right thing to do, yes. 

> I'll have a look.  As I do not run FreeBSD myself, it would 
> be great if you could somehow test it.
> 

When you say that you will have a look, does that mean that you want
to rework the patch yourself?

I'm willing (and was expecting) to open a pull request on GitHub and
do testing as well as any required rewriting per your review. If you
want to do the work I'm of course willing to test any changes you make
on Lysator's server.

Cordially,
Andreas Kempe

From julien at trigofacile.com  Mon Mar 28 16:21:31 2022
From: julien at trigofacile.com (=?iso-8859-1?Q?Julien_=C9LIE?=)
Date: Mon, 28 Mar 2022 16:21:31 +0000
Subject: nnrpd: adding blacklistd support
In-Reply-To: <YkHFhut2tg/G0kit@shipon.lysator.liu.se>
References: <Yj3zPAuMR2LApcfc@shipon.lysator.liu.se>
 <afe744b2-9e79-5dae-e72c-02119c9b69d2@trigofacile.com>,
 <YkHFhut2tg/G0kit@shipon.lysator.liu.se>
Message-ID: <64aeb4485a5d471cbdde625fed773ef3@trigofacile.com>

Hi Andreas,

> Adding it as --with-blacklistd sounds like the right thing to do, yes. 
>
>> I'll have a look.? As I do not run FreeBSD myself, it would 
>> be great if you could somehow test it.
> 
> When you say that you will have a look, does that mean that you want
> to rework the patch yourself?
>
> I'm willing (and was expecting) to open a pull request on GitHub and
> do testing as well as any required rewriting per your review.

Oh, that's kind of you.  It will save me time to do other work for INN
for the next major release.
Of course I don't mind your working on a pull request.
As we did not have GitHub until last year, I was accustomed to
reworking myself patches sent to our mailing-lists.

The idea would be to create a new m4/blacklistd.m4 file (based for
instance on m4/canlock.m4), add related glue in configure.ac and
Makefile.global.in, and surround the new code in nnrpd with
#if defined(HAVE_BLACKLISTD) instructions.

There is an entry in MANIFEST to add too.

Maybe a note about blacklistd in doc/pod/nnrpd.pod? (or any other
file you think more appropriate)
And mention --with-blacklistd in doc/pod/install.pod.

As GitHub continuous integration is run on Ubuntu, it cannot be
tested (so there is nothing to change in the ci directory I think).


Many thanks to you.  It is greatly appreciated!

-- 
Julien ?LIE

From kempe at lysator.liu.se  Mon Mar 28 20:52:12 2022
From: kempe at lysator.liu.se (Andreas Kempe)
Date: Mon, 28 Mar 2022 22:52:12 +0200
Subject: nnrpd: adding blacklistd support
In-Reply-To: <64aeb4485a5d471cbdde625fed773ef3@trigofacile.com>
References: <Yj3zPAuMR2LApcfc@shipon.lysator.liu.se>
 <afe744b2-9e79-5dae-e72c-02119c9b69d2@trigofacile.com>
 <YkHFhut2tg/G0kit@shipon.lysator.liu.se>
 <64aeb4485a5d471cbdde625fed773ef3@trigofacile.com>
Message-ID: <YkIf/N+gKidIwnSg@shipon.lysator.liu.se>

On Mon, Mar 28, 2022 at 04:21:31PM +0000, Julien ?LIE wrote:
> Hi Andreas,
> 
> > Adding it as --with-blacklistd sounds like the right thing to do, yes. 
> >
> >> I'll have a look.? As I do not run FreeBSD myself, it would 
> >> be great if you could somehow test it.
> > 
> > When you say that you will have a look, does that mean that you want
> > to rework the patch yourself?
> >
> > I'm willing (and was expecting) to open a pull request on GitHub and
> > do testing as well as any required rewriting per your review.
> 
> Oh, that's kind of you.  It will save me time to do other work for INN
> for the next major release.
> Of course I don't mind your working on a pull request.
> As we did not have GitHub until last year, I was accustomed to
> reworking myself patches sent to our mailing-lists.
> 

Happy to help! When I want a feature, I'm not adverse to putting in
some work to get it.

> The idea would be to create a new m4/blacklistd.m4 file (based for
> instance on m4/canlock.m4), add related glue in configure.ac and
> Makefile.global.in, and surround the new code in nnrpd with
> #if defined(HAVE_BLACKLISTD) instructions.
> 
> There is an entry in MANIFEST to add too.
> 
> Maybe a note about blacklistd in doc/pod/nnrpd.pod? (or any other
> file you think more appropriate)
> And mention --with-blacklistd in doc/pod/install.pod.
> 
> As GitHub continuous integration is run on Ubuntu, it cannot be
> tested (so there is nothing to change in the ci directory I think).
> 
> 

Your suggestions sound good. I'll open a pull request on Github for
review when I have made the changes.

> Many thanks to you.  It is greatly appreciated!
> 
> -- 
> Julien ?LIE

Cordially,
Andreas Kempe

From kempe at lysator.liu.se  Tue Mar 29 15:00:57 2022
From: kempe at lysator.liu.se (Andreas Kempe)
Date: Tue, 29 Mar 2022 17:00:57 +0200
Subject: nnrpd: adding blacklistd support
In-Reply-To: <YkIf/N+gKidIwnSg@shipon.lysator.liu.se>
References: <Yj3zPAuMR2LApcfc@shipon.lysator.liu.se>
 <afe744b2-9e79-5dae-e72c-02119c9b69d2@trigofacile.com>
 <YkHFhut2tg/G0kit@shipon.lysator.liu.se>
 <64aeb4485a5d471cbdde625fed773ef3@trigofacile.com>
 <YkIf/N+gKidIwnSg@shipon.lysator.liu.se>
Message-ID: <YkMfKU+/VUDbqyKH@shipon.lysator.liu.se>

On Mon, Mar 28, 2022 at 10:52:12PM +0200, Andreas Kempe wrote:
> On Mon, Mar 28, 2022 at 04:21:31PM +0000, Julien ?LIE wrote:
> > Hi Andreas,
> > 
> > > Adding it as --with-blacklistd sounds like the right thing to do, yes. 
> > >
> > >> I'll have a look.? As I do not run FreeBSD myself, it would 
> > >> be great if you could somehow test it.
> > > 
> > > When you say that you will have a look, does that mean that you want
> > > to rework the patch yourself?
> > >
> > > I'm willing (and was expecting) to open a pull request on GitHub and
> > > do testing as well as any required rewriting per your review.
> > 
> > Oh, that's kind of you.  It will save me time to do other work for INN
> > for the next major release.
> > Of course I don't mind your working on a pull request.
> > As we did not have GitHub until last year, I was accustomed to
> > reworking myself patches sent to our mailing-lists.
> > 
> 
> Happy to help! When I want a feature, I'm not adverse to putting in
> some work to get it.
> 
> > The idea would be to create a new m4/blacklistd.m4 file (based for
> > instance on m4/canlock.m4), add related glue in configure.ac and
> > Makefile.global.in, and surround the new code in nnrpd with
> > #if defined(HAVE_BLACKLISTD) instructions.
> > 
> > There is an entry in MANIFEST to add too.
> > 
> > Maybe a note about blacklistd in doc/pod/nnrpd.pod? (or any other
> > file you think more appropriate)
> > And mention --with-blacklistd in doc/pod/install.pod.
> > 
> > As GitHub continuous integration is run on Ubuntu, it cannot be
> > tested (so there is nothing to change in the ci directory I think).
> > 
> > 
> 
> Your suggestions sound good. I'll open a pull request on Github for
> review when I have made the changes.
> 

I've submitted a pull request for review at
https://github.com/InterNetNews/inn/pull/234 for those interested.

> > Many thanks to you.  It is greatly appreciated!
> > 
> > -- 
> > Julien ?LIE
> 

Cordially,
Andreas Kempe

From jesse.rehmer at blueworldhosting.com  Wed Mar 30 08:49:07 2022
From: jesse.rehmer at blueworldhosting.com (Jesse Rehmer)
Date: Wed, 30 Mar 2022 03:49:07 -0500
Subject: INN 2.7.0 feeding "local" newsgroup to peers
Message-ID: <be7013da-afcf-e7a1-2169-bb48170bb88d@blueworldhosting.com>

Greetings,

I'm noticing odd behavior with a new INN 2.7.0 setup.  When I post to 
the "local" newsgroup on my server it is being sent to many peers I 
would not expect.  I'm using newsfeeds configurations given to me by 
peers and there are a mix of styles.  So I'm not sure if almost all of 
my peers are providing an improper newsfeeds config, or if something has 
changed.

Examples of newsfeeds configurations where "local" was fed to peers:

        :*,!*.bina*,!*.bain*,!*.dateien*,!*.pictures*,!junk/!local\
        :Ajfp,C20,G12,U5,<32768,Tm\
        :innfeed!

        :*,@*.bina*,@*.bain*,@*.dateien*,@*.pictures*/!local\
        :Afjp,Tm:innfeed!

        :*,!unidata.*,@*.bina*,@*.bain*,@*.dateien*,@*.pictures*/!local\
        :Ajp,Tm,<65536:innfeed!

        :*,!junk/!local,\
        :Ajp,Tm,<512000:innfeed!

        :*,!control*,!junk,!local.*,\
        !@alt.bin*, at alt.dvd*,!@*pedophil.*,@*dateien*,!@*.bain*,\
        !@*.biana*,!@*.biinaries*,!@*bina*,!@*.bineries*,!@*.binia*,\
        !@*.binries*,!@*.cd.image*,!@*.files.images*,!@*.mp3*,\
        :Afjp,Tm,<262144:innfeed!


The only example out of several peers with a local exclusion that did 
*not* feed the article to the peer:

   :!*,uk.*,cam.*,ed.*,alt.*,\
   gnu.*,demon.*,eternal-september.*,argonet.*,24hoursupport.*,\
   comp.*,news.*,soc.*,humanities.*,sci.*,talk.*,rec.*,misc.*,\
   at.*,aus.*,be.*,ch.*,cz.*,de.*,dk.*,ee.*,es.*,esp.*,\
   fr.*,grk.*,ie.*,hun.*,is.*,it.*,italia.*,malta.*,nl.*,\
   nz.*,pl.*,pt.*,se.*,sfnet.*,sk.*,us.*,\
   @*.bain*,@*.binar*,@*.mp3*,@*.pictures*,@*.biana*,@*.biinaries*,\
   @*.dateien*,@*.binaer,@*.warez*, at alt.bin*, at unidata.*\
   /!local\
   :<65536,Afjp,Tm,Wmn:innfeed!

Header from an article that was fed to peers:

Path: 
usenet.blueworldhosting.com!.POSTED.023-084-030-207.res.spectrum.com!not-for-mail
From: Jesse Rehmer <jrehmer at blueworldhosting.com>
Newsgroups: local
Subject: t
Date: Wed, 30 Mar 2022 03:22:02 -0500
Organization: BlueWorld Hosting USENET
Message-ID: <t213va$2f1q$2 at bwh01.blueworldhosting.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 30 Mar 2022 08:22:02 -0000 (UTC)
Injection-Info: bwh01.blueworldhosting.com; posting-account="<*>"; 
posting-host="023-084-030-207.res.spectrum.com:23.84.30.207";
	logging-data="80954"; mail-complaints-to="usenet at blueworldhosting.com"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
  Gecko/20100101 Thunderbird/91.7.0
Cancel-Lock: sha1:00ax9nzaxJCmPVz2Yl638deRdhM= 
sha256:NHsaIBg+szcH4ETKON90eInITjACXQK6oejqBHl6Aw0=
	sha1:mNuGRo8Ve9svhl490cs6KYVlyuQ= 
sha256:L3wJ8+JMYmKKysLdkWf+1V3L4cpvR21Jd9cvUAJQ/eY=
Content-Language: en-US
Xref: usenet.blueworldhosting.com local:1

Regards,

Jesse Rehmer

From kjonca at o2.pl  Wed Mar 30 09:39:18 2022
From: kjonca at o2.pl (=?iso-8859-2?Q?Kamil_Jo=F1ca?=)
Date: Wed, 30 Mar 2022 11:39:18 +0200
Subject: INN 2.7.0 feeding "local" newsgroup to peers
In-Reply-To: <be7013da-afcf-e7a1-2169-bb48170bb88d@blueworldhosting.com>
 (Jesse Rehmer's message of "Wed, 30 Mar 2022 03:49:07 -0500")
References: <be7013da-afcf-e7a1-2169-bb48170bb88d@blueworldhosting.com>
Message-ID: <87zgl73hkp.fsf@alfa.kjonca>

Jesse Rehmer <jesse.rehmer at blueworldhosting.com> writes:

> Greetings,
>
> I'm noticing odd behavior with a new INN 2.7.0 setup.  When I post to

Why do you think it is odd?
One general remark: the "/!local" part of of line is taken into account
against "Distribution:" header, not 'Newsgroup:" header.
So if you have no distribution header in you example - it should be
irrelevant (Correct me if I am wrong)


> the "local" newsgroup on my server it is being sent to many peers I 
> would not expect.  I'm using newsfeeds configurations given to me by
> peers and there are a mix of styles.  So I'm not sure if almost all of 
> my peers are providing an improper newsfeeds config, or if something
> has changed.
>
> Examples of newsfeeds configurations where "local" was fed to peers:
>
>        :*,!*.bina*,!*.bain*,!*.dateien*,!*.pictures*,!junk/!local\
>        :Ajfp,C20,G12,U5,<32768,Tm\
>        :innfeed!
this config will aaccept newsgroup named "local" (because of first "*") 

>
>        :*,@*.bina*,@*.bain*,@*.dateien*,@*.pictures*/!local\
>        :Afjp,Tm:innfeed!
similary first "*" accept local

>
>        :*,!unidata.*,@*.bina*,@*.bain*,@*.dateien*,@*.pictures*/!local\
>        :Ajp,Tm,<65536:innfeed!
>
>        :*,!junk/!local,\
>        :Ajp,Tm,<512000:innfeed!
also first "*"

>
>        :*,!control*,!junk,!local.*,\
>        !@alt.bin*, at alt.dvd*,!@*pedophil.*,@*dateien*,!@*.bain*,\
>        !@*.biana*,!@*.biinaries*,!@*bina*,!@*.bineries*,!@*.binia*,\
>        !@*.binries*,!@*.cd.image*,!@*.files.images*,!@*.mp3*,\
>        :Afjp,Tm,<262144:innfeed!
>
also first '*", here '!local.*" excludes subgroups of local
(ie. local.a,local.b) but no "local" itself.
>
> The only example out of several peers with a local exclusion that did
> *not* feed the article to the peer:
>
>   :!*,uk.*,cam.*,ed.*,alt.*,\
>   gnu.*,demon.*,eternal-september.*,argonet.*,24hoursupport.*,\
>   comp.*,news.*,soc.*,humanities.*,sci.*,talk.*,rec.*,misc.*,\
>   at.*,aus.*,be.*,ch.*,cz.*,de.*,dk.*,ee.*,es.*,esp.*,\
>   fr.*,grk.*,ie.*,hun.*,is.*,it.*,italia.*,malta.*,nl.*,\
>   nz.*,pl.*,pt.*,se.*,sfnet.*,sk.*,us.*,\
>   @*.bain*,@*.binar*,@*.mp3*,@*.pictures*,@*.biana*,@*.biinaries*,\
>   @*.dateien*,@*.binaer,@*.warez*, at alt.bin*, at unidata.*\
>   /!local\
>   :<65536,Afjp,Tm,Wmn:innfeed!

here you exclude everything (!*) and then enable explictly some groups
and no "local" group.


>
> Header from an article that was fed to peers:
>
> Path:
> usenet.blueworldhosting.com!.POSTED.023-084-030-207.res.spectrum.com!not-for-mail
> From: Jesse Rehmer <jrehmer at blueworldhosting.com>
> Newsgroups: local
> Subject: t
> Date: Wed, 30 Mar 2022 03:22:02 -0500
> Organization: BlueWorld Hosting USENET
> Message-ID: <t213va$2f1q$2 at bwh01.blueworldhosting.com>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 7bit
> Injection-Date: Wed, 30 Mar 2022 08:22:02 -0000 (UTC)
> Injection-Info: bwh01.blueworldhosting.com; posting-account="<*>";
> posting-host="023-084-030-207.res.spectrum.com:23.84.30.207";
> 	logging-data="80954"; mail-complaints-to="usenet at blueworldhosting.com"
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
>  Gecko/20100101 Thunderbird/91.7.0
> Cancel-Lock: sha1:00ax9nzaxJCmPVz2Yl638deRdhM=
> sha256:NHsaIBg+szcH4ETKON90eInITjACXQK6oejqBHl6Aw0=
> 	sha1:mNuGRo8Ve9svhl490cs6KYVlyuQ=
> 	sha256:L3wJ8+JMYmKKysLdkWf+1V3L4cpvR21Jd9cvUAJQ/eY=
> Content-Language: en-US
> Xref: usenet.blueworldhosting.com local:1
>
> Regards,
>
> Jesse Rehmer

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

From julien at trigofacile.com  Wed Mar 30 21:03:47 2022
From: julien at trigofacile.com (=?UTF-8?Q?Julien_=c3=89LIE?=)
Date: Wed, 30 Mar 2022 23:03:47 +0200
Subject: INN 2.7.0 feeding "local" newsgroup to peers
In-Reply-To: <be7013da-afcf-e7a1-2169-bb48170bb88d@blueworldhosting.com>
References: <be7013da-afcf-e7a1-2169-bb48170bb88d@blueworldhosting.com>
Message-ID: <c7f01198-816c-459e-1247-3af09a0e1f1e@trigofacile.com>

Hi Jesse,

> I'm noticing odd behavior with a new INN 2.7.0 setup.? When I post to 
> the "local" newsgroup on my server it is being sent to many peers I 
> would not expect.? I'm using newsfeeds configurations given to me by 
> peers and there are a mix of styles.? So I'm not sure if almost all of 
> my peers are providing an improper newsfeeds config, or if something has 
> changed.

Your peers do not know that you carry a newsgroup named "local".

Besides what Kamil already said, I would just add:

>  ?????? :*,!*.bina*,!*.bain*,!*.dateien*,!*.pictures*,!junk/!local\

When "*" is used, pseudo-groups like control.cancel are explicitly 
marked to be transferred.  If you then exclude newsgroups, you should
also exclude control articles for these newsgroups.

:*,!*.bina*,!*.bain*,!*.dateien*,!*.pictures*,!junk,!control,!control.*

would be better.  This way, control articles for news.software.nntp will 
still be fed (as they follow the propagation of their Newsgroups header 
field), but control articles for alt.xxx.binary won't be fed (which is 
what you expect).
Otherwise, all the contents of the pseudo-groups is sent, whatever the 
Newsgroups header field is.


>  ?????? :*,!control*,!junk,!local.*,\

Better say "!control,!control.*" as a hierarchy named controller.* for 
instance would not be fed with that pattern.


>  ?????? !@*.biana*,!@*.biinaries*,!@*bina*,!@*.bineries*,!@*.binia*,\

Is the "!@" pattern really working?  ("@" would be enough, I'm not sure 
"!@" is valid)

-- 
Julien ?LIE

??L'?ternit?, c'est long, surtout vers la fin.?? (Woody Allen)