suck feeds my private, in-house, newserver.

cleanfeed's installed using software downloaded from:

<https://github.com/crooks/cleanfeed>

spamassassin is not deployed at present.

Path: is unusable as a cleanfeed filter because in my case it always
contains:

Path: meow.home.net!not-for mail

On the other hand, Injection-Info indeed identifies google-groups:

Injection-Info: google-groups.googlegroups.com; posting-host= ...

cleanfeed.local was copied from cleanfeed.local.sample and this snippet
was added:

sub local_filter_last {
if ($hdr{Injection-Info} =~ /google-groups\.google\.com/) {
return reject("Reject google-groups posting to $hdr{Newsgroups}");
};

Can anyone offer any ideas as to why it won't work? Given how the very
next "recipe" in cleanfeed.local does indeed work:

if (not $hdr{References} and
$hdr{__LINES__} > 25 and
$hdr{__LINES__} < 150 and
scalar @groups > 4 and
scalar @followups > 4) {
if ($hdr{__BODY__} =~ /MI5/ or
$hdr{Subject} =~ /M.{1,3}I.{1,3}5/) {
saveart('mi5');
return reject('MI5 Filter');
};
};

it indicates a "healthy" cleanfeed install.

Thank you in advance for any advice.

Danke,

--
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

The following filter de-peers google for me:

sub local_filter_first {
if ($hdr{'Injection-Info'} =~ /google-groups\.googlegroups\.com/) {
return reject('google-groups');
};

It turns out google\.com was erroneously used initially instead of
googlegroups\.com .

Danke,

--
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

Hi,

Don a tapoté le 26/11/2023 05:34:
> The following filter de-peers google for me:
>
> sub local_filter_first {
> if ($hdr{'Injection-Info'} =~ /google-groups\.googlegroups\.com/) {
> return reject('google-groups');
> };
>
> It turns out google\.com was erroneously used initially instead of
> googlegroups\.com .
>
> Danke,
>

I have done it by cleanfeed but here it is not filtered for all groups.

For all groups, the best way is in newsfeeds file :

$BADPATHS=google-groups.googlegroups.com
ME/$BADPATHS:::

--
Stéphane

yamo' a présenté l'énoncé suivant :
> Hi,
>
> Don a tapoté le 26/11/2023 05:34:
>> The following filter de-peers google for me:
>>
>> sub local_filter_first {
>> if ($hdr{'Injection-Info'} =~ /google-groups\.googlegroups\.com/) {
>> return reject('google-groups');
>> };
>>
>> It turns out google\.com was erroneously used initially instead of
>> googlegroups\.com .
>>
>> Danke,
>>
>
>
> I have done it by cleanfeed but here it is not filtered for all groups.
>
> For all groups, the best way is in newsfeeds file :
>
>
> $BADPATHS=google-groups.googlegroups.com
> ME/$BADPATHS:::

Some people are posting real messages from Google.
It's a shame to filter everything from us.

Le 26/11/2023 à 19:44, llp a écrit :

> Some people are posting real messages from Google.
> It's a shame to filter everything from us.

You can't destroy usenet for a few posters.

llp <llp@news.usenet.ovh> wrote:

>>. . .

>Some people are posting real messages from Google.
>It's a shame to filter everything from us.

Why is that? This large-scale injection of spam through Google Groups is
an enormous hint to those posting the tiny number of legitimate articles
that it's long past time to become a subscriber on a genuine News
server. They made the choice to continue to associate with a News site
that has created massive problems for all other News administrators.

If other News administrators implement a passive Usenet Death Penalty as
a spam countermeasure, then their articles won't propogate widely. They
cannot be unaware of the consequence.

Adam H. Kerman avait soumis l'idée :
> llp <llp@news.usenet.ovh> wrote:
>
>>> . . .
>
>> Some people are posting real messages from Google.
>> It's a shame to filter everything from us.
>
> Why is that? This large-scale injection of spam through Google Groups is
> an enormous hint to those posting the tiny number of legitimate articles
> that it's long past time to become a subscriber on a genuine News
> server. They made the choice to continue to associate with a News site
> that has created massive problems for all other News administrators.
>
> If other News administrators implement a passive Usenet Death Penalty as
> a spam countermeasure, then their articles won't propogate widely. They
> cannot be unaware of the consequence.

In theory, you're right.
In practice, it will split usenet in two. Those who fully filter
Googlegroups and those who don't. I find it hard to believe that large
commercial servers blacklist google. Without this, an udp of the other
servers will be useless. For the time being, I prefer the nocems
solution for filtering this spam.
I've seen that eternal-september, i2pn or usenet.ovh have followed this
path, rejecting spam as soon as it arrives on the server and setting up
nocems for the other servers.

llp <contact@usenet.ovh> wrote:
>Adam H. Kerman avait soumis l'id�e :
>>llp <llp@news.usenet.ovh> wrote:

>>>>. . .

>>>Some people are posting real messages from Google.
>>>It's a shame to filter everything from us.

>>Why is that? This large-scale injection of spam through Google Groups is
>>an enormous hint to those posting the tiny number of legitimate articles
>>that it's long past time to become a subscriber on a genuine News
>>server. They made the choice to continue to associate with a News site
>>that has created massive problems for all other News administrators.

>>If other News administrators implement a passive Usenet Death Penalty as
>>a spam countermeasure, then their articles won't propogate widely. They
>>cannot be unaware of the consequence.

>In theory, you're right.
>In practice, it will split usenet in two. Those who fully filter
>Googlegroups and those who don't.

This isn't Usenet's problem. The consequences are well known at the
point to the poster who has chosen not to become a user on a genuine
News server that isn't so widely rejected.

>I find it hard to believe that large
>commercial servers blacklist google. Without this, an udp of the other
>servers will be useless. For the time being, I prefer the nocems
>solution for filtering this spam.

>I've seen that eternal-september, i2pn or usenet.ovh have followed this
>path, rejecting spam as soon as it arrives on the server and setting up
>nocems for the other servers.

You aren't the one writing them. The ones who are have been putting an
incredible amount of work into it and at some point will conclude that
it's just not worth it.

On 2023-11-26, llp <llp@news.usenet.ovh> wrote:
> Some people are posting real messages from Google.

Unfortunately, these genuine, well-meaning postings often try try to
help someone from 1992, who probably figured out their problem in the
three decades since. :)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

llp <llp@news.usenet.ovh> writes:
> yamo' a présenté l'énoncé suivant :
>> Don a tapoté le 26/11/2023 05:34:
>>> The following filter de-peers google for me:
>>> sub local_filter_first {
>>> if ($hdr{'Injection-Info'} =~ /google-groups\.googlegroups\.com/) {
>>> return reject('google-groups');
>>> };
>>> It turns out google\.com was erroneously used initially instead of
>>> googlegroups\.com .
>>> Danke,
>>>
>>
>>
>> I have done it by cleanfeed but here it is not filtered for all groups.
>>
>> For all groups, the best way is in newsfeeds file :
>>
>>
>> $BADPATHS=google-groups.googlegroups.com
>> ME/$BADPATHS:::
>
> Some people are posting real messages from Google.
> It's a shame to filter everything from us.

It is a shame, but other, less spammy, news servers do exist, and you
can use them instead if you wish.

(I’m still not blocking Google, not that it would affect anyone but me
if I did, but the persistent spam is making me increasingly sympathetic
to the server operators who do block Google).

--
https://www.greenend.org.uk/rjk/

Le 26/11/2023, Adam H. Kerman a supposé :
> llp <contact@usenet.ovh> wrote:
>> Adam H. Kerman avait soumis l'idée :
>>> llp <llp@news.usenet.ovh> wrote:
>
>>>>> . . .
>
>>>> Some people are posting real messages from Google.
>>>> It's a shame to filter everything from us.
>
>>> Why is that? This large-scale injection of spam through Google Groups is
>>> an enormous hint to those posting the tiny number of legitimate articles
>>> that it's long past time to become a subscriber on a genuine News
>>> server. They made the choice to continue to associate with a News site
>>> that has created massive problems for all other News administrators.
>
>>> If other News administrators implement a passive Usenet Death Penalty as
>>> a spam countermeasure, then their articles won't propogate widely. They
>>> cannot be unaware of the consequence.
>
>> In theory, you're right.
>> In practice, it will split usenet in two. Those who fully filter
>> Googlegroups and those who don't.
>
> This isn't Usenet's problem. The consequences are well known at the
> point to the poster who has chosen not to become a user on a genuine
> News server that isn't so widely rejected.
>
>> I find it hard to believe that large
>> commercial servers blacklist google. Without this, an udp of the other
>> servers will be useless. For the time being, I prefer the nocems
>> solution for filtering this spam.
>
>> I've seen that eternal-september, i2pn or usenet.ovh have followed this
>> path, rejecting spam as soon as it arrives on the server and setting up
>> nocems for the other servers.
>
> You aren't the one writing them. The ones who are have been putting an
> incredible amount of work into it and at some point will conclude that
> it's just not worth it.

Sorry, you're wrong ;-)
I'm the administrator of the usenet.ovh server and I've written
nocembot for produce Nocem (as well as a filter for cleanfeed to
reject spam at source on my server).
But, yes, it takes time.

llp <contact@usenet.ovh> wrote:
>Le 26/11/2023, Adam H. Kerman a suppos� :
>> llp <contact@usenet.ovh> wrote:
>>> Adam H. Kerman avait soumis l'id�e :
>>>> llp <llp@news.usenet.ovh> wrote:
>>
>>>>>> . . .
>>
>>>>> Some people are posting real messages from Google.
>>>>> It's a shame to filter everything from us.
>>
>>>> Why is that? This large-scale injection of spam through Google Groups is
>>>> an enormous hint to those posting the tiny number of legitimate articles
>>>> that it's long past time to become a subscriber on a genuine News
>>>> server. They made the choice to continue to associate with a News site
>>>> that has created massive problems for all other News administrators.
>>
>>>> If other News administrators implement a passive Usenet Death Penalty as
>>>> a spam countermeasure, then their articles won't propogate widely. They
>>>> cannot be unaware of the consequence.
>>
>>> In theory, you're right.
>>> In practice, it will split usenet in two. Those who fully filter
>>> Googlegroups and those who don't.
>>
>> This isn't Usenet's problem. The consequences are well known at the
>> point to the poster who has chosen not to become a user on a genuine
>> News server that isn't so widely rejected.
>>
>>> I find it hard to believe that large
>>> commercial servers blacklist google. Without this, an udp of the other
>>> servers will be useless. For the time being, I prefer the nocems
>>> solution for filtering this spam.
>>
>>> I've seen that eternal-september, i2pn or usenet.ovh have followed this
>>> path, rejecting spam as soon as it arrives on the server and setting up
>>> nocems for the other servers.
>>
>> You aren't the one writing them. The ones who are have been putting an
>> incredible amount of work into it and at some point will conclude that
>> it's just not worth it.

>Sorry, you're wrong ;-)
>I'm the administrator of the usenet.ovh server and I've written
>nocembot for produce Nocem (as well as a filter for cleanfeed to
>reject spam at source on my server).
>But, yes, it takes time.

I apologize.

On 11/25/23 11:52, Don wrote:
> suck feeds my private, in-house, newserver.

Okay.

I can't help with cleanfeed itself. That being said, I do have the
following thoughts.

> Path: is unusable as a cleanfeed filter because in my case it always
> contains:
>
> Path: meow.home.net!not-for mail

That seems like something I'd try to correct.

Specifically I'd try to reconfigure things to append your news server
(new on left / old on right) to the existing Path: header value.

So you could filter in the Google Groups Path: header part.

Or possibly have whatever you're using to pull down articles simply not
save articles from Google Groups or simply not re-inject them into your
server.

The Path; header, including Google parts, should be in the articles that
you are downloading.

I'd suggest you try using that instead of re-inventing the wheel.

> On the other hand, Injection-Info indeed identifies google-groups:
>
> Injection-Info: google-groups.googlegroups.com; posting-host= ...

Yes.

Sorry, I can't help with cleanfeed itself.

> Thank you in advance for any advice.

Good luck.

--
Grant. . . .

On 11/26/23 12:44, llp wrote:
> Some people are posting real messages from Google.

Yep.

> It's a shame to filter everything from us.

Agreed.

But each news administrator needs to make a decision of how much time
they are willing to spend retroactively cleaning up Google Groups spam
vs proactively blocking all Google Groups messages. It's a personal
choice for them alone to make.

Grant. . . .

Grant wrote:
> Don wrote:
>> suck feeds my private, in-house, newserver.
>
> Okay.
>
> I can't help with cleanfeed itself. That being said, I do have the
> following thoughts.
>
>> Path: is unusable as a cleanfeed filter because in my case it always
>> contains:
>>
>> Path: meow.home.net!not-for mail
>
> That seems like something I'd try to correct.
>
> Specifically I'd try to reconfigure things to append your news server
> (new on left / old on right) to the existing Path: header value.
>
> So you could filter in the Google Groups Path: header part.
>
> Or possibly have whatever you're using to pull down articles simply not
> save articles from Google Groups or simply not re-inject them into your
> server.
>
> The Path; header, including Google parts, should be in the articles that
> you are downloading.
>
> I'd suggest you try using that instead of re-inventing the wheel.

Yes. Something is obviously unintentionally broken and needs to be
fixed. yamo' shows a superior solution earlier in the thread.

Any ideas from the group on how to make suck properly handle headers
is appreciated in advance.

Danke,

--
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

Don <g@crcomp.net> wrote:

> Grant wrote:
> > Don wrote:
> >> suck feeds my private, in-house, newserver.
> >
> > Okay.
> >
> > I can't help with cleanfeed itself. That being said, I do have the
> > following thoughts.
> >
> >> Path: is unusable as a cleanfeed filter because in my case it always
> >> contains:
> >>
> >> Path: meow.home.net!not-for mail
> >
> > That seems like something I'd try to correct.
> >
> > Specifically I'd try to reconfigure things to append your news server
> > (new on left / old on right) to the existing Path: header value.
> >
> > So you could filter in the Google Groups Path: header part.
> >
> > Or possibly have whatever you're using to pull down articles simply not
> > save articles from Google Groups or simply not re-inject them into your
> > server.
> >
> > The Path; header, including Google parts, should be in the articles that
> > you are downloading.
> >
> > I'd suggest you try using that instead of re-inventing the wheel.
> >
>
> Yes. Something is obviously unintentionally broken and needs to be
> fixed. yamo' shows a superior solution earlier in the thread.
>
> Any ideas from the group on how to make suck properly handle headers
> is appreciated in advance.
>
> Danke,
>

I don't know if this might be useful, it works very well for me
as a Newsreader filter. I killfile on User-Agent: G2/1.0

--
^Ï^. Sn!pe, PA, FIBS - Professional Crastinator.
My pet rock Gordon just is.

Google Groups articles not seen here unless poster is whitelisted.

Hi,

Don a tapoté :
>
> Yes. Something is obviously unintentionally broken and needs to be
> fixed. yamo' shows a superior solution earlier in the thread.

My cleanfeed.local has those lines (inside other many lines) :

sub local_flag_spamsource2 {
return 1 if $hdr{'Injection-Info'} =~ /google-groups.googlegroups.com|posting.uzoreto.com/;
return 1 if $hdr{'X-Complaints-To'} =~ /abuse\@usenetserver.com/;
return 0;
};

sub local_filter_last {

if(local_flag_spamsource2){
if (not $hdr{Newsgroups} =~ /^news\.|^fr\./i) {
return reject( 'spam google?');
};
};
};

Beware my copy past may be broken!
You can check with :

perl -wc /etc/news/filter/cleanfeed/etc/cleanfeed.local

You can adapt them for your config...

>
> Any ideas from the group on how to make suck properly handle headers
> is appreciated in advance.

I only use innfeed. I never used suck.

--
Stéphane
Sorry for my bad English...

Don wrote:
> Grant wrote:
>> Don wrote:
>>> suck feeds my private, in-house, newserver.
>>
>> Okay.
>>
>> I can't help with cleanfeed itself. That being said, I do have the
>> following thoughts.
>>
>>> Path: is unusable as a cleanfeed filter because in my case it always
>>> contains:
>>>
>>> Path: meow.home.net!not-for mail
>>
>> That seems like something I'd try to correct.

In the end, my innd install perfectly handles the Path: header. After
too much dectective work it turns out easynews uses Path: not-for-mail
on every single article it hosts - easynews personnel perverted the
Path: protocol.

Danke,

--
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

Thus spake "Don" <g@crcomp.net>
> Don wrote:

> In the end, my innd install perfectly handles the Path: header. After
> too much dectective work it turns out easynews uses Path: not-for-mail
> on every single article it hosts - easynews personnel perverted the
> Path: protocol.

,-------------------------------------------------------------------
| "not-for-mail" is a common <tail-entry>.
`-------------------------------------------------------------------

https://www.rfc-editor.org/rfc/rfc5537.html#section-3.2.2

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

Ray Banana <rayban@raybanana.net> writes:

> Thus spake "Don" <g@crcomp.net>
>
>> Don wrote:
>
>> In the end, my innd install perfectly handles the Path: header. After
>> too much dectective work it turns out easynews uses Path: not-for-mail
>> on every single article it hosts - easynews personnel perverted the
>> Path: protocol.
>
> ,-------------------------------------------------------------------
> | "not-for-mail" is a common <tail-entry>.
> `-------------------------------------------------------------------
>
> https://www.rfc-editor.org/rfc/rfc5537.html#section-3.2.2

It's not usually the *whole* path though. xsusenet do that. Perhaps only
on the reader side, to "protect their users' anonymity" or
whatever. Their IP address looks to belong to Abavia.