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.
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>
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!
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?
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?
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.
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.
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.
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.
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.
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.
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, 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.
. . .
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.
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.)
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.
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.
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
(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]).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 08:13:23 |
| Calls: | 10,387 |
| Calls today: | 2 |
| Files: | 14,058 |
| Messages: | 6,416,655 |