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.

On Tue, 23 Jan 2024 15:22:20 +0100, Andrew <Doug@hyperspace.vogon.gov> wrote:
>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 . . .

>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)
>Message-ID: <ede23807-bcd1-4127-a56b-869bb9e85a87n@googlegroups.com>

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?

D wrote:
> On Tue, 23 Jan 2024 15:22:20 +0100, Andrew <Doug@hyperspace.vogon.gov> wrote:
>> 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 . . .
>
>> 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)
>> Message-ID: <ede23807-bcd1-4127-a56b-869bb9e85a87n@googlegroups.com>
>
> 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-8be1ec16adbcn@googlegroups.com>
<8f159134-39de-4647-9b04-3939ed5b430cn@googlegroups.com>
<afa0e914-bcbf-4866-9901-af0ea16da3efn@googlegroups.com>
<ee613204-bf25-4630-ad27-9eb54229414an@googlegroups.com>
<84677263-2636-401a-a1cb-1d2cda74ec32n@googlegroups.com>
<5f148f71-46c6-479d-86bc-d51fb273b609n@googlegroups.com>
<b83c3d95-9c87-4e4b-b4b8-adec5abf04bcn@googlegroups.com>
<02e61d6d-9d6d-42c1-80ef-ff869fcb2d3en@googlegroups.com>
<705f95f4-4b32-4a19-b029-371d7394b851n@googlegroups.com>
<8e9e67d5-b9b6-42f2-b2f1-5d9fb4b12459n@googlegroups.com>
<c976636f-152b-4eef-a522-3357e200e034n@googlegroups.com>
<90bcddb0-d360-4c8b-97c4-b968c5e1376en@googlegroups.com>
<9d135ea4-5217-4177-8884-8539fdcf5a77n@googlegroups.com>
<08c61c46-0c51-46d5-aa42-d3f6a008d15dn@googlegroups.com>
<5607d3c9-57d1-416d-87fe-ceebad23dc6dn@googlegroups.com>
<94106756-8c13-44ec-8a95-27138d6b6dd1n@googlegroups.com>
<d2e65173-5609-4cfb-b9c3-a6e93aa45e1cn@googlegroups.com>
<5354c136-6629-41e8-9173-6a84458e4831n@googlegroups.com>
<e2408f2a-da4a-4b96-93ab-def8ccd73e48n@googlegroups.com>
<197ad258-7c15-473a-8943-e932fcd3f843n@googlegroups.com>
<c2e20f16-d2b8-427a-b379-4d1771fed4ebn@googlegroups.com>
<f72aa419-931a-4f9d-8630-9bd7d8b477d6n@googlegroups.com>
<86aa6ad2-3705-4a6a-b231-c5f6e2884a0cn@googlegroups.com>
<ec7580d3-d763-42e6-912f-ed721849614en@googlegroups.com>
<458fe507-27d7-4a7e-82c8-f8cce3b19542n@googlegroups.com>
<5fd58e92-3944-4e4b-85a9-b056cc6c1820n@googlegroups.com>
<0f32a5c1-2479-416f-8f94-e894a9e4d0e9n@googlegroups.com>
<c0bc469b-e0d7-4dd1-90c3-618f033c7342n@googlegroups.com>
<32ec4db3-ad6e-4e22-90e6-9cfbea0c731bn@googlegroups.com>
<b5a69404-9591-4db1-8d7f-bb748aa930acn@googlegroups.com>
<bd96c741-03e9-4d4f-9bc3-c13724f7ad23n@googlegroups.com>
<5c0aefe5-21fe-42b3-8345-2eb1aa41fdf9n@googlegroups.com>
<07bf0daa-720a-4058-b2c1-9b525c03e141n@googlegroups.com>
<7ae3b8d9-387d-4c91-b523-68ecdece0f02n@googlegroups.com>
<f8709fb6-96b6-4b31-9f64-8759bbd83f1dn@googlegroups.com>
<c8faaeb4-1967-49eb-8be7-3dbd998a43b3n@googlegroups.com>
<143d2170-4de1-4d04-b203-63e9578b0369n@googlegroups.com>
<3801fdf3-64e7-47d4-a960-8ab5cc28ff0an@googlegroups.com>
<b6a46074-90c9-4616-8993-82a0911e614fn@googlegroups.com> August 2023
<4e3afb76-ce00-4646-8833-b64e7c609d3bn@googlegroups.com> July 2023
<c8541300-f480-4233-a26b-13be9ecaa9e7n@googlegroups.com> July 2023
<d814626f-7ec7-4824-af34-ab2aba77a93an@googlegroups.com> July 2023

spam spam spam!

In article <uoou75$1jep7$1@paganini.bofh.team>,
Andrew <Doug@hyperspace.vogon.gov> wrote:
>D wrote:
>> On Tue, 23 Jan 2024 15:22:20 +0100, Andrew <Doug@hyperspace.vogon.gov> wrote:
>>> 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 . . .
>>
>>> 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)
>>> Message-ID: <ede23807-bcd1-4127-a56b-869bb9e85a87n@googlegroups.com>
>>
>> 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-8be1ec16adbcn@googlegroups.com>
><8f159134-39de-4647-9b04-3939ed5b430cn@googlegroups.com>
><afa0e914-bcbf-4866-9901-af0ea16da3efn@googlegroups.com>
><ee613204-bf25-4630-ad27-9eb54229414an@googlegroups.com>
><84677263-2636-401a-a1cb-1d2cda74ec32n@googlegroups.com>
><5f148f71-46c6-479d-86bc-d51fb273b609n@googlegroups.com>
><b83c3d95-9c87-4e4b-b4b8-adec5abf04bcn@googlegroups.com>
><02e61d6d-9d6d-42c1-80ef-ff869fcb2d3en@googlegroups.com>
><705f95f4-4b32-4a19-b029-371d7394b851n@googlegroups.com>
><8e9e67d5-b9b6-42f2-b2f1-5d9fb4b12459n@googlegroups.com>
><c976636f-152b-4eef-a522-3357e200e034n@googlegroups.com>
><90bcddb0-d360-4c8b-97c4-b968c5e1376en@googlegroups.com>
><9d135ea4-5217-4177-8884-8539fdcf5a77n@googlegroups.com>
><08c61c46-0c51-46d5-aa42-d3f6a008d15dn@googlegroups.com>
><5607d3c9-57d1-416d-87fe-ceebad23dc6dn@googlegroups.com>
><94106756-8c13-44ec-8a95-27138d6b6dd1n@googlegroups.com>
><d2e65173-5609-4cfb-b9c3-a6e93aa45e1cn@googlegroups.com>
><5354c136-6629-41e8-9173-6a84458e4831n@googlegroups.com>
><e2408f2a-da4a-4b96-93ab-def8ccd73e48n@googlegroups.com>
><197ad258-7c15-473a-8943-e932fcd3f843n@googlegroups.com>
><c2e20f16-d2b8-427a-b379-4d1771fed4ebn@googlegroups.com>
><f72aa419-931a-4f9d-8630-9bd7d8b477d6n@googlegroups.com>
><86aa6ad2-3705-4a6a-b231-c5f6e2884a0cn@googlegroups.com>
><ec7580d3-d763-42e6-912f-ed721849614en@googlegroups.com>
><458fe507-27d7-4a7e-82c8-f8cce3b19542n@googlegroups.com>
><5fd58e92-3944-4e4b-85a9-b056cc6c1820n@googlegroups.com>
><0f32a5c1-2479-416f-8f94-e894a9e4d0e9n@googlegroups.com>
><c0bc469b-e0d7-4dd1-90c3-618f033c7342n@googlegroups.com>
><32ec4db3-ad6e-4e22-90e6-9cfbea0c731bn@googlegroups.com>
><b5a69404-9591-4db1-8d7f-bb748aa930acn@googlegroups.com>
><bd96c741-03e9-4d4f-9bc3-c13724f7ad23n@googlegroups.com>
><5c0aefe5-21fe-42b3-8345-2eb1aa41fdf9n@googlegroups.com>
><07bf0daa-720a-4058-b2c1-9b525c03e141n@googlegroups.com>
><7ae3b8d9-387d-4c91-b523-68ecdece0f02n@googlegroups.com>
><f8709fb6-96b6-4b31-9f64-8759bbd83f1dn@googlegroups.com>
><c8faaeb4-1967-49eb-8be7-3dbd998a43b3n@googlegroups.com>
><143d2170-4de1-4d04-b203-63e9578b0369n@googlegroups.com>
><3801fdf3-64e7-47d4-a960-8ab5cc28ff0an@googlegroups.com>
><b6a46074-90c9-4616-8993-82a0911e614fn@googlegroups.com> August 2023
><4e3afb76-ce00-4646-8833-b64e7c609d3bn@googlegroups.com> July 2023
><c8541300-f480-4233-a26b-13be9ecaa9e7n@googlegroups.com> July 2023
><d814626f-7ec7-4824-af34-ab2aba77a93an@googlegroups.com> July 2023
>
>spam spam spam!

Sounds like Google Groups!
--
Member - Liberal International This is doctor@nk.ca Ici doctor@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

Andrew a formulé ce mardi :
> 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

llp wrote:
> Andrew a formulé ce mardi :
>> 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.

Le 23/01/2024 à 19:10, Andrew a écrit :

> 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.

Andrew <Doug@hyperspace.vogon.gov> wrote:
>llp wrote:
>>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.

>>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.

Andrew <Doug@hyperspace.vogon.gov> wrote:

> 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.

Adam H. Kerman <ahk@chinet.com> wrote:

> 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.

On Wed, 24 Jan 2024 02:09:35 +0000, Adam W. wrote:

> 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.

noel <deletethis@invalid.lan> wrote:

> 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.

On Wed, 24 Jan 2024 13:12:44 -0000 (UTC), gof-cut-this-news@cut-this-chmurka.net.invalid (Adam W.) wrote:
>noel <deletethis@invalid.lan> wrote:
>
>> 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

On Wed, 24 Jan 2024 13:12:44 +0000, Adam W. wrote:

> noel <deletethis@invalid.lan> wrote:
>
>> 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.

> 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.)

noel <deletethis@invalid.lan> wrote:
>On Wed, 24 Jan 2024 13:12:44 +0000, Adam W. wrote:
>>noel <deletethis@invalid.lan> wrote:

>>>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.

>>. . .

noel <deletethis@invalid.lan> wrote:

>> 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?

> 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.

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

Hopefully.

> (* 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).

On Fri, 26 Jan 2024 17:06:05 +0000, Adam W. wrote:

>
> 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.

>
>> 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.

On 27 Jan 2024 23:55:23 +1000, noel <deletethis@invalid.lan> wrote:
> On Fri, 26 Jan 2024 17:06:05 +0000, Adam W. wrote:
>
>> 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.

On Sat, 27 Jan 2024 18:23:39 +0100, Matija Nalis <mnalis-news@voyager.hr> wrote:
>On 27 Jan 2024 23:55:23 +1000, noel <deletethis@invalid.lan> wrote:
>> On Fri, 26 Jan 2024 17:06:05 +0000, Adam W. wrote:
>>> 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"

In article <c2e787ba289ac652bfe7599666c28a76@dizum.com>, D <J@M> wrote:
>
>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

On 28 Jan 2024 23:14:51 -0000, kludge@panix.com wrote:
>In article <c2e787ba289ac652bfe7599666c28a76@dizum.com>, D <J@M> wrote:
>>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!

Matija Nalis <mnalis-news@voyager.hr> wrote:

> (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