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,
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.
. . .
Some people are posting real messages from Google.
It's a shame to filter everything from us.
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'ide :
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.
Some people are posting real messages from Google.
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.
llp <contact@usenet.ovh> wrote:
Adam H. Kerman avait soumis l'ide :
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.
Le 26/11/2023, Adam H. Kerman a suppos :
llp <contact@usenet.ovh> wrote:
Adam H. Kerman avait soumis l'ide :
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.
suck feeds my private, in-house, newserver.
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= ...
Thank you in advance for any advice.
Some people are posting real messages from Google.
It's a shame to filter everything from us.
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.
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,
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.
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.
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.
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 33:08:50 |
| Calls: | 10,391 |
| Calls today: | 2 |
| Files: | 14,064 |
| Messages: | 6,417,128 |