Discussion:
More Thai spam in comp.lang.cobol
(too old to reply)
Andrew
2024-01-23 14:22:20 UTC
Permalink
Thai-language spam has made a comeback in comp.lang.cobol. The last
time I looked, Ray B on Eternal September was spam-assassinating it to
oblivion but Ivo Gandolfo (Paganini, the server I'm using to post this)
has let almost all of it through.
As far as I can see, every post to the newsgroup in 2024 is spam, apart
from one today by a "David L". Again, afaics, all of them (including
David L's) have Google Groups Message-IDs.
D
2024-01-23 15:13:10 UTC
Permalink
Post by Andrew
Thai-language spam has made a comeback in comp.lang.cobol. The last
time I looked, Ray B on Eternal September was spam-assassinating it to
oblivion but Ivo Gandolfo (Paganini, the server I'm using to post this)
has let almost all of it through.
As far as I can see, every post to the newsgroup in 2024 is spam, apart
from one today by a "David L". Again, afaics, all of them (including
David L's) have Google Groups Message-IDs.
sample header . . .
Post by Andrew
Path: n...!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.cobol
Date: Tue, 23 Jan 2024 06:30:31 -0800 (PST)
that's only about ~338 googlespams since 24 december 2023;
" " " ~238 " " 1 january 2024;

chickenfeed by google standards, in 30 days it'll be water under
the bridge . . . what will the invincible google groups division
do after their discharge from active duty . . . play tiddlywinks?
Andrew
2024-01-23 17:49:25 UTC
Permalink
Post by D
Post by Andrew
Thai-language spam has made a comeback in comp.lang.cobol. The last
time I looked, Ray B on Eternal September was spam-assassinating it to
oblivion but Ivo Gandolfo (Paganini, the server I'm using to post this)
has let almost all of it through.
As far as I can see, every post to the newsgroup in 2024 is spam, apart
from one today by a "David L". Again, afaics, all of them (including
David L's) have Google Groups Message-IDs.
sample header . . .
Post by Andrew
Path: n...!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.cobol
Date: Tue, 23 Jan 2024 06:30:31 -0800 (PST)
that's only about ~338 googlespams since 24 december 2023;
" " " ~238 " " 1 january 2024;
chickenfeed by google standards, in 30 days it'll be water under
the bridge . . . what will the invincible google groups division
do after their discharge from active duty . . . play tiddlywinks?
<4855901a-46eb-4ee7-82fe-***@googlegroups.com>
<8f159134-39de-4647-9b04-***@googlegroups.com>
<afa0e914-bcbf-4866-9901-***@googlegroups.com>
<ee613204-bf25-4630-ad27-***@googlegroups.com>
<84677263-2636-401a-a1cb-***@googlegroups.com>
<5f148f71-46c6-479d-86bc-***@googlegroups.com>
<b83c3d95-9c87-4e4b-b4b8-***@googlegroups.com>
<02e61d6d-9d6d-42c1-80ef-***@googlegroups.com>
<705f95f4-4b32-4a19-b029-***@googlegroups.com>
<8e9e67d5-b9b6-42f2-b2f1-***@googlegroups.com>
<c976636f-152b-4eef-a522-***@googlegroups.com>
<90bcddb0-d360-4c8b-97c4-***@googlegroups.com>
<9d135ea4-5217-4177-8884-***@googlegroups.com>
<08c61c46-0c51-46d5-aa42-***@googlegroups.com>
<5607d3c9-57d1-416d-87fe-***@googlegroups.com>
<94106756-8c13-44ec-8a95-***@googlegroups.com>
<d2e65173-5609-4cfb-b9c3-***@googlegroups.com>
<5354c136-6629-41e8-9173-***@googlegroups.com>
<e2408f2a-da4a-4b96-93ab-***@googlegroups.com>
<197ad258-7c15-473a-8943-***@googlegroups.com>
<c2e20f16-d2b8-427a-b379-***@googlegroups.com>
<f72aa419-931a-4f9d-8630-***@googlegroups.com>
<86aa6ad2-3705-4a6a-b231-***@googlegroups.com>
<ec7580d3-d763-42e6-912f-***@googlegroups.com>
<458fe507-27d7-4a7e-82c8-***@googlegroups.com>
<5fd58e92-3944-4e4b-85a9-***@googlegroups.com>
<0f32a5c1-2479-416f-8f94-***@googlegroups.com>
<c0bc469b-e0d7-4dd1-90c3-***@googlegroups.com>
<32ec4db3-ad6e-4e22-90e6-***@googlegroups.com>
<b5a69404-9591-4db1-8d7f-***@googlegroups.com>
<bd96c741-03e9-4d4f-9bc3-***@googlegroups.com>
<5c0aefe5-21fe-42b3-8345-***@googlegroups.com>
<07bf0daa-720a-4058-b2c1-***@googlegroups.com>
<7ae3b8d9-387d-4c91-b523-***@googlegroups.com>
<f8709fb6-96b6-4b31-9f64-***@googlegroups.com>
<c8faaeb4-1967-49eb-8be7-***@googlegroups.com>
<143d2170-4de1-4d04-b203-***@googlegroups.com>
<3801fdf3-64e7-47d4-a960-***@googlegroups.com>
<b6a46074-90c9-4616-8993-***@googlegroups.com> August 2023
<4e3afb76-ce00-4646-8833-***@googlegroups.com> July 2023
<c8541300-f480-4233-a26b-***@googlegroups.com> July 2023
<d814626f-7ec7-4824-af34-***@googlegroups.com> July 2023

spam spam spam!
The Doctor
2024-01-23 17:53:22 UTC
Permalink
Post by Andrew
Post by D
Post by Andrew
Thai-language spam has made a comeback in comp.lang.cobol. The last
time I looked, Ray B on Eternal September was spam-assassinating it to
oblivion but Ivo Gandolfo (Paganini, the server I'm using to post this)
has let almost all of it through.
As far as I can see, every post to the newsgroup in 2024 is spam, apart
from one today by a "David L". Again, afaics, all of them (including
David L's) have Google Groups Message-IDs.
sample header . . .
n...!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Post by D
Post by Andrew
Newsgroups: comp.lang.cobol
Date: Tue, 23 Jan 2024 06:30:31 -0800 (PST)
that's only about ~338 googlespams since 24 december 2023;
" " " ~238 " " 1 january 2024;
chickenfeed by google standards, in 30 days it'll be water under
the bridge . . . what will the invincible google groups division
do after their discharge from active duty . . . play tiddlywinks?
spam spam spam!
Sounds like Google Groups!
--
Member - Liberal International This is ***@nk.ca Ici ***@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen
Birthday 29 Jan 1969 Born Redhill , England, UK Beware https://mindspring.com
llp
2024-01-23 18:02:51 UTC
Permalink
Thai-language spam has made a comeback in comp.lang.cobol. The last time I
looked, Ray B on Eternal September was spam-assassinating it to oblivion but
Ivo Gandolfo (Paganini, the server I'm using to post this) has let almost all
of it through.
Isn't the conclusion simple?
--
Admin of news.usenet.ovh
Andrew
2024-01-23 18:10:59 UTC
Permalink
Post by llp
Thai-language spam has made a comeback in comp.lang.cobol.  The last
time I looked, Ray B on Eternal September was spam-assassinating it to
oblivion but Ivo Gandolfo (Paganini, the server I'm using to post
this) has let almost all of it through.
Isn't the conclusion simple?
Yeah, it would be good if Ivo took a little more notice of cancels his
peers have issued. That is in an ideal world, given what I'm paying for
this service, I can't really complain.
Eric M
2024-01-23 18:16:15 UTC
Permalink
Post by Andrew
Yeah, it would be good if Ivo took a little more notice of cancels his
peers have issued. That is in an ideal world, given what I'm paying for
this service, I can't really complain.
In french-speaking newsgroups this kind of spam is cancelled immediatly :)
This will end in one month anyway.
Adam H. Kerman
2024-01-23 19:01:28 UTC
Permalink
Post by Andrew
Post by llp
Thai-language spam has made a comeback in comp.lang.cobol.  The last
time I looked, Ray B on Eternal September was spam-assassinating it to
oblivion but Ivo Gandolfo (Paganini, the server I'm using to post
this) has let almost all of it through.
Isn't the conclusion simple?
Yeah, it would be good if Ivo took a little more notice of cancels his
peers have issued. That is in an ideal world, given what I'm paying for
this service, I can't really complain.
There were no cancels being issued for spam and abuse coming through
Google Groups. This wasn't being handled like counter abuse in fr.*.

These were NoCeMs. And yes, they figured out a way to run the articles
in question through Spam Assassin as one of the steps as Cleanfeed isn't
capable of "learning" from pattern recognition.

No cancels were issued at all. That's why it wasn't controversial, even
with false positives and false negatives and all the tweaking taking
place.

Discuss with Ivo directly whose NoCeMs he's willing to process, if any.
Adam W.
2024-01-24 02:09:35 UTC
Permalink
Post by Adam H. Kerman
No cancels were issued at all. That's why it wasn't controversial, even
with false positives and false negatives and all the tweaking taking
place.
Yes, this is true. NoCeMs are opt-in by principle, cancels not always.
noel
2024-01-24 03:18:49 UTC
Permalink
Post by Adam W.
NoCeMs are opt-in by principle, cancels not always.
I've used Dnews since pre-mid 90's, like nocems, its never honored
cancels by default requiring opt-in explicit config changes to allow
them, which I've never done, anyone who gives a damn never honors cancels
for the same BS reasons we've been reading about paganini's oliver doing
in *.fr, that same boring BS saga happened in the 90's... jesus people...
did we not learn anything from those days, clearly some not so.

in plain english, if you accept nocems or honoring cancels, you have no
right to bitch, lessons were learned decades ago not to ever do this
because its abused, you have the power to re disable it.

The answer is your local filtering, sure, it might require from time to
time modifying your filtering rules, and might also require more heavy
handed actions like many of us took on google, but overall it works... I
rarely tinker with my rules anymore because that along with spamassassin
and bayes, sorts most of it out.
Adam W.
2024-01-24 13:12:44 UTC
Permalink
Post by noel
I've used Dnews since pre-mid 90's, like nocems, its never honored
cancels by default requiring opt-in explicit config changes to allow
them, which I've never done, anyone who gives a damn never honors cancels
for the same BS reasons we've been reading about paganini's oliver doing
in *.fr, that same boring BS saga happened in the 90's... jesus people...
did we not learn anything from those days, clearly some not so.
Cancel-locks sort of solved this problem. I accept cancels when they're
properly signed.

As to NoCeMs, everyone should evaluate given NoCeM source and decide if
filtering rules applied fit their needs.

But I doubt there will be any more need for it when Google Groups are
finally closed. I just hope they won't postpone the date.
D
2024-01-24 14:56:35 UTC
Permalink
Post by Adam W.
Post by noel
I've used Dnews since pre-mid 90's, like nocems, its never honored
cancels by default requiring opt-in explicit config changes to allow
them, which I've never done, anyone who gives a damn never honors cancels
for the same BS reasons we've been reading about paganini's oliver doing
in *.fr, that same boring BS saga happened in the 90's... jesus people...
did we not learn anything from those days, clearly some not so.
Cancel-locks sort of solved this problem. I accept cancels when they're
properly signed.
As to NoCeMs, everyone should evaluate given NoCeM source and decide if
filtering rules applied fit their needs.
But I doubt there will be any more need for it when Google Groups are
finally closed. I just hope they won't postpone the date.
it's a biblical two-mouthed gladius (double-edged sword) either way;
seems like their best option is to run it through . . . only 29 days
noel
2024-01-26 00:43:41 UTC
Permalink
Post by Adam W.
Post by noel
I've used Dnews since pre-mid 90's, like nocems, its never honored
cancels by default requiring opt-in explicit config changes to allow
them, which I've never done, anyone who gives a damn never honors
cancels for the same BS reasons we've been reading about paganini's
oliver doing in *.fr, that same boring BS saga happened in the 90's...
jesus people...
did we not learn anything from those days, clearly some not so.
Cancel-locks sort of solved this problem. I accept cancels when they're
properly signed.
Seen all that fail too, trusted people cna and did often, go rogue.
Post by Adam W.
As to NoCeMs, everyone should evaluate given NoCeM source and decide if
filtering rules applied fit their needs.
But I doubt there will be any more need for it when Google Groups are
finally closed. I just hope they won't postpone the date.
Wont make any difference here, since google's trash has been stopped at
the door for many, many months, its a one liner in my cleanfeed(*) file.

Though yes, usenet as a whole is about to become a much better place.

(* DNews's cleanfeed file, it doesnt resemble cleanfeed being
distributed for INN and from what I was told it wont work with INN, so I
assume vice versa is also true.)
Adam H. Kerman
2024-01-26 01:54:23 UTC
Permalink
Post by noel
Post by Adam W.
Post by noel
I've used Dnews since pre-mid 90's, like nocems, its never honored
cancels by default requiring opt-in explicit config changes to allow
them, which I've never done, anyone who gives a damn never honors
cancels for the same BS reasons we've been reading about paganini's
oliver doing in *.fr, that same boring BS saga happened in the 90's...
jesus people...
did we not learn anything from those days, clearly some not so.
Cancel-locks sort of solved this problem. I accept cancels when they're
properly signed.
Seen all that fail too, trusted people cna and did often, go rogue.
What are you talking about? Third parties DO NOT have access to use
cancel-lock.
Post by noel
Post by Adam W.
. . .
Adam W.
2024-01-26 17:06:05 UTC
Permalink
Post by noel
Post by Adam W.
Cancel-locks sort of solved this problem. I accept cancels when they're
properly signed.
Seen all that fail too, trusted people cna and did often, go rogue.
Only two parties can cancel a post protected with a cancel-lock. One is
the author himself, another one is his newsadmin. Are you talking about
these scenarios? Someone cancelling all posts he posted, or all posts that
were sent using his server?
Post by noel
Wont make any difference here, since google's trash has been stopped at
the door for many, many months, its a one liner in my cleanfeed(*) file.
Filtering everything from Google is an easy way. I didn't want to do this,
because genuine posters still post with Google. It's also very easy to do
with a simple reader-side filter, so I didn't think it was a good idea to
make that choice for my users.
Post by noel
Though yes, usenet as a whole is about to become a much better place.
Hopefully.
Post by noel
(* DNews's cleanfeed file, it doesnt resemble cleanfeed being
distributed for INN and from what I was told it wont work with INN, so I
assume vice versa is also true.)
I don't know about DNews, but INN's cleanfeed is just a Perl script with a
certain, INN-specific API (and there's a Python equivalent too).
noel
2024-01-27 13:55:23 UTC
Permalink
Post by Adam W.
Only two parties can cancel a post protected with a cancel-lock. One is
the author himself, another one is his newsadmin. Are you talking about
these scenarios? Someone cancelling all posts he posted, or all posts
that were sent using his server?
rogue news admins were a massive problem in 90's, I have no reason to
believe much has changed.
Post by Adam W.
Post by noel
Wont make any difference here, since google's trash has been stopped at
the door for many, many months, its a one liner in my cleanfeed(*)
file.
Filtering everything from Google is an easy way. I didn't want to do this,
because genuine posters still post with Google. It's also very easy to
do with a simple reader-side filter, so I didn't think it was a good
idea to make that choice for my users.
Collateral damage is what gets thigs fixed. You don't run mail servers do
you, because the same principle applies, if you have sh1teloads of crap
from a domain that wont get off their rearend and do anything, you
blacklist them (waves at ye auld AOL), google definately has its email
spammers, but nothing like on the scale from usenet, though there have
been brief periods where we have blacklisted gmail for days because of
spam storms, think what you will about microsoft, but they do take
spamming seriously and are proactive in stopping it and not just
reactive, never had to blacklist outlook, live, or hotmail, yahoo back
in its heyday was nearly as bad as google though.

Blacklisting bad actors generally is a last resort to prompt those admins
to get off their butt and fix their stuff, google showed they have zero
care factor, so many servers took action on google who finally admit they
lost their battle with abusers, and to fix it is in the too hard basket,
and is easier for them to de-peer from the world, end resullt is the
same, usenet becomes a better place.

google got a wake up call, they initially considered themselves "too big
to block"... it's just a shame it took them so long to realise nobody but
nobody, is too big to blacklist.
Matija Nalis
2024-01-27 17:23:39 UTC
Permalink
Post by noel
Post by Adam W.
Only two parties can cancel a post protected with a cancel-lock. One is
the author himself, another one is his newsadmin. Are you talking about
these scenarios? Someone cancelling all posts he posted, or all posts
that were sent using his server?
rogue news admins were a massive problem in 90's, I have no reason to
believe much has changed.
Could you explain what abuse scenario you have in mind exactly, and
specifically how it relates to cancel-lock?

Sure, rogue newsadmin can cancel any and all the articles on their
newsserver if they like to. Rogue newsadmin can also try to send rogue
cancels to other servers (vast majority of which are properly configured,
and will just disregard such rogue cancels)

That is however unrelated to cancel-lock, which allows only original poster
to cancel only their articles on other news servers which do implement
cancel-lock (i.e. which disregard all incoming cancel messages _expect_ the
cancels which have same crypto-signature as the original post they attempt
to cancel).

Whether the person posted the original article on the newsserver which has
rouge newsadmin or a good one is not affecting cancel-lock functionality
(IOW, the rougue newsadmin cannot pretend to be original poster and cancel
their posts on servers which implement cancel-lock technology -- only the
original poster can [1]).

See https://www.rfc-editor.org/rfc/rfc8315.html for details

[1] to avoid nitpicking: the "original poster" meaning "person having access
to private key used to sign the original post, which should be just the
original poster" (and disregarding extreme situations of e.g. someone
holding a gun to your head and asking that you hand over your private
key so they can pretend to be you and cancel your Usenet posts against
your will).
--
Opinions above are GNU-copylefted.
D
2024-01-27 18:05:33 UTC
Permalink
Post by Matija Nalis
Post by noel
Post by Adam W.
Only two parties can cancel a post protected with a cancel-lock. One is
the author himself, another one is his newsadmin. Are you talking about
these scenarios? Someone cancelling all posts he posted, or all posts
that were sent using his server?
rogue news admins were a massive problem in 90's, I have no reason to
believe much has changed.
Could you explain what abuse scenario you have in mind exactly, and
specifically how it relates to cancel-lock?
Sure, rogue newsadmin can cancel any and all the articles on their
newsserver if they like to. Rogue newsadmin can also try to send rogue
cancels to other servers (vast majority of which are properly configured,
and will just disregard such rogue cancels)
That is however unrelated to cancel-lock, which allows only original poster
to cancel only their articles on other news servers which do implement
cancel-lock (i.e. which disregard all incoming cancel messages _expect_ the
cancels which have same crypto-signature as the original post they attempt
to cancel).
Whether the person posted the original article on the newsserver which has
rouge newsadmin or a good one is not affecting cancel-lock functionality
(IOW, the rougue newsadmin cannot pretend to be original poster and cancel
their posts on servers which implement cancel-lock technology -- only the
original poster can [1]).
See https://www.rfc-editor.org/rfc/rfc8315.html for details
[1] to avoid nitpicking: the "original poster" meaning "person having access
to private key used to sign the original post, which should be just the
original poster" (and disregarding extreme situations of e.g. someone
holding a gun to your head and asking that you hand over your private
key so they can pretend to be you and cancel your Usenet posts against
your will).
sounds like what old-timers called "alchemy" . . . turning lead into gold;
probably nothing ever posted via usenet would "threaten national security"
k***@panix.com
2024-01-28 23:14:51 UTC
Permalink
Post by D
sounds like what old-timers called "alchemy" . . . turning lead into gold;
probably nothing ever posted via usenet would "threaten national security"
It might threaten the security of the Church of Scientology though.
--scott
D
2024-01-29 00:05:12 UTC
Permalink
Post by k***@panix.com
Post by D
sounds like what old-timers called "alchemy" . . . turning lead into gold;
probably nothing ever posted via usenet would "threaten national security"
It might threaten the security of the Church of Scientology though.
--scott
not even using long remailer chains with tor and whole message encryption
could protect against that branch of government. . . they've got auditors!
Adam W.
2024-01-29 01:35:58 UTC
Permalink
Post by Matija Nalis
(IOW, the rougue newsadmin cannot pretend to be original poster and cancel
their posts on servers which implement cancel-lock technology -- only the
original poster can [1]).
Not always.

See the description of canlockadmin here:

https://www.eyrie.org/~eagle/software/inn/docs-2.7/inn-secrets.conf.html
Adam W.
2024-01-24 02:07:59 UTC
Permalink
Post by Andrew
Thai-language spam has made a comeback in comp.lang.cobol. The last
time I looked, Ray B on Eternal September was spam-assassinating it to
oblivion but Ivo Gandolfo (Paganini, the server I'm using to post this)
has let almost all of it through.
Looks like all these spams are caught by my filters without any false
positives. Results are published as NoCeMs by news.chmurka.net.

I redirect these spams to local groups to monitor the flow and catch any
false positives. The flow is huge, I didn't catch any false positive yet.
Loading...