Re: Subject: Windows XP Vulnerabilities vs. Windows 10 Vulnerablilities - NO Contest!

[JJ]

On Thu, 15 Jul 2021 20:27:11 -0500, Me...@invalid.com wrote:
> Read 'em and weep, Win 10 sheeple.
>
> Windows XP Vulnerabilities: 741
> https://www.cvedetails.com/vulnerability-list.php?vendor_id=26&product_id=739&version_id=0&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&cweid=0&order=1&trc=741&sha=96656e0273b52e8473fbf8b6371fe2ed4a0f8ae8
>
> Windows 10 vulnerabilities: 2,261
> https://www.cvedetails.com/vulnerability-list.php?vendor_id=26&product_id=32238&version_id=0&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&cweid=0&order=1&trc=2261&sha=41e451b72c2e412c0a1cb8cb1dcfee3d16d51c44

That just shows how Windows 10 is prematurely released, including the
updates. They say "rapid development". But it also mean not well tested. In
fact, testing is not the proority of "rapid development". The priority is
only for fast paced development.

But one of the good things about newer Windows versions is that, they lure
hackers and malware authors away from from older Windows versions. Leaving
older Windows version systems in peace.

[😉 Good Guy 😉]

On 16/07/2021 02:27, Me...@invalid.com wrote:

Read 

CAN YOU JUST FUCK OFF.
CAN YOU JUST FUCK OFF.
CAN YOU JUST FUCK OFF.
CAN YOU JUST FUCK OFF.
CAN YOU JUST FUCK OFF.

STOP VANDALISING THIS NEWSGROUP WITH YOUR CRAP LINKS.

You don't have the necessary intelligence to know what is secure and what is not and in what context is security best discussed. Windows XP is no longer supported so idiots like you can keep singing about it for years to come.

YOU ARE A BLIND FOOL! GO FUCK YOURSELF.

--

With over 1.3 billion devices now running Windows 10, customer satisfaction is higher than any previous version of windows.

[Jolly]

Same to you, you brainwashed officious twit !

[gfre...@aol.com]

On Sat, 17 Jul 2021 00:06:53 +0700, JJ <jj4p...@gmail.com> wrote:

>But one of the good things about newer Windows versions is that, they lure
>hackers and malware authors away from from older Windows versions. Leaving
>older Windows version systems in peace.

I wonder when the last hack was aimed at a W98 machine.

[😉 Good Guy 😉]

On 17/07/2021 00:40, gfre...@aol.com wrote:

I wonder when the last hack was aimed at a W98 machine.

Yesterday. You didn't hear about it because nobody is using it and it wasn't worth reporting!!!.

[R.Wieser]

Jolly,

> Same to you, you brainwashed officious twit !

Just put him into your killfile.

You know, its rather amusing to see the hypocrisy with which GG complains
about "crap links". Absolutitly *none* of the subjects he has posted has
anything to do with XP [1], and his links are therefore absolutily worthless
to anyone here.

[1] from 45 he started last six months most are about Win 10 or related,
quiete a number about non-computer stuff (ufos, argentinians, gaza city,
biden, cancel culture, amazon, twitter, etc) and /not a single one/ about
XP.

Also, most of all of those subjects he posted were pretty-much copy-pasted
from news sites.

His demands that we all read his posts as HTML but first have to ask his
permission to do so is just the cherry on top.

Regards,
Rudy Wieser

[JJ]

On Sat, 17 Jul 2021 10:37:13 +0200, R.Wieser wrote:
> Jolly,
>
>> Same to you, you brainwashed officious twit !
>
> Just put him into your killfile.

For me, I already did. Quite early, that is.

Somehow, my news client know something's wrong with all of his posts. Each
time I try to retrieve any of his posts' message body, the news client gives
me a silent treatment and stops responding - refusing to load any of his
messages. So, I just killfile him.

I don't know what happended to him. He used to be a good usenet citizen.
Rarely trolls and posts off topics. But now, all of his posts are crap.

[JJ]

And I wonder when was the last virus made for OS/2 or even DOS & CP/M. :)

Cause I think most, if not, all of the people who still use old OSes are
loyal and honest fans.

[R.Wieser]

JJ,

>> Just put him into your killfile.
>
> For me, I already did. Quite early, that is.

I've been giving him the benefit of the doubt for a while, but after seeing
he just kept posting stuff with no relation to this newsgroup I also did.

> Somehow, my news client know something's wrong with all of his
> posts. Each time I try to retrieve any of his posts' message body,
> the news client gives me a silent treatment and stops responding

Hmmm.. strange (but befitting him :-) ). IE6 doesn't have a problem with
it, and a peek just now at the raw message (headers & body) doesn't show
anything outof the ordinary that I can see.

> I don't know what happended to him. He used to be a good usenet
> citizen. Rarely trolls and posts off topics. But now, all of his posts
> are crap.

I noticed the same and sometimes wonder what might have caused it ...

Regards,
Rudy Wieser

[Apd]

"R.Wieser" wrote:
> Jolly,
>
>> Same to you, you brainwashed officious twit !
>
> Just put him into your killfile.

No need here. Thankfully, Eternal September rejects HTML posts so I
never see his crap unless someone responds to it.

[R.Wieser]

Apd,

> Thankfully, Eternal September rejects HTML posts so I
> never see his crap unless someone responds to it.

Thats *the* major downside of actually removing someones posts (either by
the server or by the reader) : as no parent to a reply can be found that
parents "killfile" status cannot be determined either.

My OE6 has that "lets just delete the message and forget all about it"
problem too. Either stooopid or an attempt to get people to pay to drop
that "E" in the middle. :-\

Regards,
Rudy Wieser

[Mayayana]

"Apd" <n...@all.invalid> wrote

| No need here. Thankfully, Eternal September rejects HTML posts so I
| never see his crap unless someone responds to it.
|

I didn't know that. I use ES, but I've been blocking Good Guy
for years, anyway. Funny thing... For many years I never blocked
anyone. It seemed rude and there weren't really problems. But
these days I block lots of people. Some are anti-social. Others
are oddballs. Some are just lonely people who like to post things
like, "I just spilled coffee on my keyboard. What do you think is
the best cleaner?"

I suppose the landscape has changed a lot. 20 years ago the
groups were alive with questions, tweaking, programming discussions...
and lots of MVPs. These days we're all old, most of the MVPs are
gone, few people are programming shareware, and most of the
on-topic questions are not so much tweaking as surviving Win10.
Or people reporting, with surprise, that they just got the latest Win10
remake and their computer is still booting.

Maybe we'll need to start a microsoft.public.prostate.tips and
then we can just use that group for all Windows issues. :)

[R.Wieser]

Merle,

Two things:

One: Learn to quote. That last "No need here" part of the quote there is
not mine.

Two: Learn to discern between talking about someone and how to get rid of
his crap.

> No, I ain't complaining about him. I'm complaining about you
> people whining

And you do not realize that you are now whining about, and (possibly) just
feeding *us* ? :-)

> the simplicity of Kill Filtering seems to escape you.

Lol.

You know what seems to have fully escaped you ? That not all newsgroup
readers handle "killfiling" in the same way, and some approaches do not give
the desired result. Also, that the "Ethernal september" usenet server, by
its deletion of certain posts, makes itself part of that problem. Are you
telling us that we are not allowed to discuss that ? Really ?

Suggestion: if you cannot grasp, or simply do not care about what others are
talking about you can always use the button which will hide that message
subtree (your reader program /does/ have such a button, no ?). Better for
you and us.

On the other hand, you could just be trolling ...

Regards,
Rudy Wieser

[Apd]

"R.Wieser" wrote:
> Apd,
>> Thankfully, Eternal September rejects HTML posts so I
>> never see his crap unless someone responds to it.
>
> Thats *the* major downside of actually removing someones posts (either by
> the server or by the reader) : as no parent to a reply can be found that
> parents "killfile" status cannot be determined either.

The "References" header will have what you need. If you can't find the
message in OE look it up on Howard Knight:
<http://al.howardknight.net/>

> My OE6 has that "lets just delete the message and forget all about it"
> problem too.

Mark as read?

> Either stooopid or an attempt to get people to pay to drop
> that "E" in the middle. :-\

?

[Apd]

"Mayayana" wrote:
> "Apd" wrote

>| No need here. Thankfully, Eternal September rejects HTML posts so I
>| never see his crap unless someone responds to it.
>
> I didn't know that.

Nor did I until GG's posts became noticeable by their absence. Then
I heard about the HTML block in one of the support groups (aioe or
ES). It's fairly recent, probably less than a year.

> I use ES, but I've been blocking Good Guy for years, anyway.

I just used to skip his posts - land on one then "next unread".

> Funny thing... For many years I never blocked
> anyone. It seemed rude and there weren't really problems. But
> these days I block lots of people. Some are anti-social. Others
> are oddballs. Some are just lonely people who like to post things
> like, "I just spilled coffee on my keyboard. What do you think is
> the best cleaner?"

I never found the need to filter until a couple of years back when a
bot started posting in a group I follow (it posts in a few). I delete
those outright. Then another poster appeared from one of the troll
groups with content-free one-liners in fully-quoted replies. That was
another delete. Finally, there's one who compulsively replies with
insults to every post made by certain people he doesn't like. He's
never contributed anything. That's another for immediate deletion.

> I suppose the landscape has changed a lot. 20 years ago the
> groups were alive with questions, tweaking, programming discussions...
> and lots of MVPs. These days we're all old, most of the MVPs are
> gone, few people are programming shareware, and most of the
> on-topic questions are not so much tweaking as surviving Win10.
> Or people reporting, with surprise, that they just got the latest Win10
> remake and their computer is still booting.

So true. This guy wants to revive Usenet and has a PDF presentation
about it:
<https://www.big-8.org/wiki/User:Jason_Evans>

I wish him luck.

> Maybe we'll need to start a microsoft.public.prostate.tips and
> then we can just use that group for all Windows issues. :)

I actually LOL'd at that (a rare thing).

[R.Wieser]

Apd,

> The "References" header will have what you need.

How ? Yes, the last entry in there tells you who the current posts parent
is, but if the parent was deleted (on the server or client), than all data
about that parent is gone. There simply is nothing to look at.

> If you can't find the message in OE look it up on Howard Knight:

:-) Yes you can. But you will than have to do that for /every reply/ to
that killfiled person. IOW, you will need to notice that a reply is
possibly to someone you have killfiled, verify it and than remove the reply.
Thats a /lot/ of work. :-\

>> My OE6 has that "lets just delete the message and forget all
>> about it" problem too.
>
> Mark as read?

OE6 has a "view" and "ignore" modi (which needs a manual addition of a
"display rule" to actually /do/ anything - something I only "recently" was
made aware of), both of which are inherited.

Though that still causes the message to be displayed and needs manual manual
labour on every reply to a non-existing (killfiled and thus deleted) parent.
IOW, a game of whack-a-mole ...

But as I am a bit of a tinkerer and hobby programmer I found a way to
disable the "delete" part of the build-in killfile. After that I wrote some
stuff to use the names in that killfile list (stored in the registry) to do
some filtering of my own, marking the caught messages as "ignore". Presto,
I do not see killfiled messages or the replies to them anymore (but can
still access them if the need is there). :-)

>> Either stooopid or an attempt to get people to pay to
>> drop that "E" in the middle. :-\
>
> ?

MS sells Outlook. Outlook Express is just the dumbed down, "try it for
free" version that gets installed with Windows (at least upto XP).

Regards,
Rudy Wieser

[JJ]

On Mon, 19 Jul 2021 03:25:36 +0100, Apd wrote:
>
> So true. This guy wants to revive Usenet and has a PDF presentation
> about it:

[snip: URL censored]

LOL. Might as well use PowerPoint, and to recommend that Usenet content
should be JavaScript... heck, WebAssembly enabled.

[Apd]

"R.Wieser" wrote:
> Apd,
[...]

>> Mark as read?
>
> OE6 has a "view" and "ignore" modi (which needs a manual addition of a
> "display rule" to actually /do/ anything - something I only "recently" was
> made aware of), both of which are inherited.
>
> Though that still causes the message to be displayed and needs manual manual
> labour on every reply to a non-existing (killfiled and thus deleted) parent.
> IOW, a game of whack-a-mole ...
>
> But as I am a bit of a tinkerer and hobby programmer I found a way to
> disable the "delete" part of the build-in killfile. After that I wrote some
> stuff to use the names in that killfile list (stored in the registry) to do
> some filtering of my own, marking the caught messages as "ignore". Presto,
> I do not see killfiled messages or the replies to them anymore (but can
> still access them if the need is there). :-)

I gather from all that you want to kill the subthreads arising from
killfiled messages. I didn't know it was even possible in OE.

>>> Either stooopid or an attempt to get people to pay to
>>> drop that "E" in the middle. :-\
>>
>> ?
>
> MS sells Outlook. Outlook Express is just the dumbed down, "try it for
> free" version that gets installed with Windows (at least upto XP).

I wasn't aware Outlook could do NNTP. An org I worked for used Outlook
for mail and OE for the internal newsgroups. I never liked Outlook,
always preferring OE which is a different product and not one I
consider to be "dumbed down".

[Apd]

WTF are you on about? I must admit I don't know how he thinks he's
going to revive it.

[R.Wieser]

Apd,

> I gather from all that you want to kill the subthreads arising
> from killfiled messages.

Yup.

> I didn't know it was even possible in OE.

It isn't. Due to that stooopid decision they made to actually /delete/ a
killfiled posters message - all of it.

> I wasn't aware Outlook could do NNTP.

Ehhhrmmm ... To be honest, I took it for granted it would due to what I
always understood as the "full product" vs "free-to-try" version relation.
I just did a search for it, and saw that Outlook doesn't actually support
NNTP. I stand corrected. Thanks for bringing it up.

> always preferring OE which is a different product

I've got nothing to compare, as I've never used Outlook. Glanced at it,
but nothing more.

Regards,
Rudy Wieser

[J. P. Gilliver (John)]

On Mon, 19 Jul 2021 at 11:33:01, R.Wieser <add...@not.available> wrote
(my responses usually follow points raised):

>Apd,
>
>> The "References" header will have what you need.
>
>How ? Yes, the last entry in there tells you who the current posts parent
>is, but if the parent was deleted (on the server or client), than all data
>about that parent is gone. There simply is nothing to look at.

I'm sure I've seen (I think "References") headers that contain
references to the entire thread (or at least as much of it as the
previous post retained). (After all, if the header is called
"References", with an s, ...)
[]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

The average age at which a woman has her first child has passed 30.
Jason Cowley, RT 2016/6/11-17

[J. P. Gilliver (John)]

On Mon, 19 Jul 2021 at 19:46:19, Apd <n...@all.invalid> wrote (my

responses usually follow points raised):

>"R.Wieser" wrote:
[]

>> MS sells Outlook. Outlook Express is just the dumbed down, "try it for
>> free" version that gets installed with Windows (at least upto XP).
>
>I wasn't aware Outlook could do NNTP. An org I worked for used Outlook
>for mail and OE for the internal newsgroups. I never liked Outlook,
>always preferring OE which is a different product and not one I
>consider to be "dumbed down".
>
>

O can't do news, but pretends it can, by calling OE (msimn); at least,
that was the case up to about 20 years ago when my employer ditched news
altogether (internal and external). Since MS don't like news, I can't
see them ever adding it to O; they've probably removed the pretence from
later versions (if only because OE wasn't supplied with later Windows
[though may still _work_ under some of them if the .exe is copied]).

[R.Wieser]

John,

> I'm sure I've seen (I think "References") headers that contain references
> to the entire thread (or at least as much of it as the previous post
> retained)

Yes, it does (which is why I said "the *last entry* in there tells you who
the current posts parent is" - emphasis mine). But how does that help ?

Mind you, none of the other stored posts can have been killfiled - they
would not have been stored if they where . :-) IOW, that means that you
could go thru all the actually stored messages, but /not one of them/ would
have a "killfile" indicator that could get inherited.

Also, the grandparent of the current post could be A-OK (read: the killfiled
parent message could be a reply into a thread started by someone else).

Regards,
Rudy Wieser

[Paul]

J. P. Gilliver (John) wrote:
> On Mon, 19 Jul 2021 at 11:33:01, R.Wieser <add...@not.available> wrote
> (my responses usually follow points raised):
>> Apd,
>>
>>> The "References" header will have what you need.
>>
>> How ? Yes, the last entry in there tells you who the current posts
>> parent
>> is, but if the parent was deleted (on the server or client), than all
>> data
>> about that parent is gone. There simply is nothing to look at.
>
> I'm sure I've seen (I think "References") headers that contain
> references to the entire thread (or at least as much of it as the
> previous post retained). (After all, if the header is called
> "References", with an s, ...)
> []

It's possible the Reference line has a ~1000 character limit,
whereas threads can easily go to very high message counts.

I don't think the NNTP design guarantees that the Reference
information is "complete". Merely that every message contains
some subset of all information.

Paul

[R.Wieser]

Paul,

> I don't think the NNTP design guarantees that the Reference
> information is "complete". Merely that every message contains some subset
> of all information.

To be able to inherit a "blacklist" flag you only need to know who the
direct parent is ...

Your remark made me curious though. Alas, I can't seem to find anything -
not even in the RFCs.

Regards,
Rudy Wieser

[J. P. Gilliver (John)]

On Tue, 20 Jul 2021 at 14:42:46, R.Wieser <add...@not.available> wrote

(my responses usually follow points raised):

>John,
>
>> I'm sure I've seen (I think "References") headers that contain references
>> to the entire thread (or at least as much of it as the previous post
>> retained)
>
>Yes, it does (which is why I said "the *last entry* in there tells you who
>the current posts parent is" - emphasis mine). But how does that help ?

Rudy,

the thread had diverged into how to block posts by x and followups to
posts by x. Someone suggested the References header could be used.
Someone - you I think - said that would only help if the
immediately-preceding post had been by x. I pointed out that the
References header (note the "s") often contained several entries, not
just that relating to the immediately-preceding post.

It depends how your newsreader killfile processing handles the
References header, assuming it does at all. If it only looks at the
thread-starter part of the References header, then it indeed wouldn't
pick up on a valid thread where the person you want to block (including
followups) came in part-way down. If it can do a "contains", then it
can.

(There's also as Paul pointed out the possibility of some newsreaders
having a limit - say y characters or maybe z [re]posts - causing the
header from the unwanted person to be lost from the thread.)

[]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

The losses on both sides at Borodino [1812], 70 miles from Moscow, are the
equivalent of a jumbo jet crashing into an area of six square miles every five
minutes for the whole ten hours of the battle, killing or wounding everyone on
board. - Andrew Roberts on Napoleon, RT 2015/6/13-19

[R.Wieser]

John,

> Someone - you I think - said that would only help if the
> immediately-preceding post had been by x.

I'm quite sure I said no such thing.

And on the off chance that you mean "parent" where you used
"immediately-preceding post" (why make up new descriptons of which the/your
definition is unknown to the reader and, from his POV, can mean/refer to
several things/posts ?), I did not say that either.

What I *did* say that it would be impossible to inherit anything from a
deleted (parent) post - including its "killfiled" status.

As for how that works for a reply-to-a-reply to a killfiled post ? I did
not even go there, as the very same applies there.

> I pointed out that the References header (note the "s") often contained
> several entries, not just that relating to the immediately-preceding post.

To which I replied that you could have read in the post you replied to
there - and you even quoted! - that both apd and myself are well aware of
that header and what its contents are.

You also dropped that tidbit into the discussion without giving any hint to
why that would be important (you did in your current reply though, see
further down).

Nonetheless, I tried to explain in my reply, by using the grandparent of a
post as an example, why that would not work. Alas, not even a hint that
you read it. Sometimess I ask myself : why do I still bother ?

> It depends how your newsreader killfile processing handles the References
> header,

That is answered by what this subthread started with. No need to bring it
up again.

> If it can do a "contains", then it can.

Explain please : Where do you get that message-id (to use into the
"References" header) for that "contains" action ? Or more specific :
/how do you know which message-id to use/ ?

Also, have you ever thought about the possibility to un-killfile a subthread
a bit lower down ? That won't be possible with your method.

Furthermore, if the "References" header contains the message-id's for the
/whole/ thread than that approach will kill /all/ replies into that thread,
regardless of if they where in the killfiled posters subthread or not ...

Regards,
Rudy Wieser

[R.Wieser]

> Furthermore, if the "References" header contains the message-id's
> for the /whole/ thread than that approach will kill /all/ replies into
> that thread, regardless of if they where in the killfiled posters
> subthread or not ...

Scratch that part, that list only goes up - child to parent - and doesn't
contain sibblings.

Regards,
Rudy Wieser

[Apd]

"Paul" wrote:
> J. P. Gilliver (John) wrote:
>> I'm sure I've seen (I think "References") headers that contain
>> references to the entire thread (or at least as much of it as the
>> previous post retained). (After all, if the header is called
>> "References", with an s, ...)
>> []
>
> It's possible the Reference line has a ~1000 character limit,
> whereas threads can easily go to very high message counts.

RFC 5322 (Internet Message Format) gives the max line length as 1000
characters (including CR/LF)

> I don't think the NNTP design guarantees that the Reference
> information is "complete". Merely that every message contains
> some subset of all information.

RFC 1036 (Standard for Interchange of USENET Messages) says:
| It is permissible to not include the entire previous "References"
| line if it is too long. An attempt should be made to include a
| reasonable number of backwards references.

Sensible newsreaders do what is called "folding" with lines which
become too long. However, OE doesn't do this with the "References"
line and eventually you can't post in a long thread when you get the
"line too long" error. Even if the message you reply to has folded
the line, OE stupidly unfolds it to add a reference. There used to be
a hack in OE5 where you could manually add an X header to your post
(save as text file first) after editing the long line and re-send.
That hack no longer works in OE6 and you have to edit the message to
which you want to reply first then reply again to it.

[R.Wieser]

Apd,

> | An attempt should be made to include a reasonable number of
> | backwards references.

:-) Although that /looks/ very helpfull, that "2.2.5. References" chapter
the above is part of does not give any specifics. I could just remove every
second message-id. Or ignore all overflow. Or remove entries from the
start of the list. All three honor the above spec., even though only one of
them is usefull.

Also, this RFC 1036 does not say anything about the order in which the
entries are supposed to appear - which was specified in RFC 850 which it
supposedly obsoletes. IOW, I would be allowed to add the currents posts
parent to the start of the "References" header, or even randomize the
entries and use that. :-) :-(

> Sensible newsreaders do what is called "folding" with lines which
> become too long. However, OE doesn't do this with the "References"
> line and eventually you can't post in a long thread when you get the
> "line too long" error.

There is another explanation, one which has got nothing to do with folding :
the total length of a header entry seems to be undefined (not in any of the
RFCs you named). Its rather possible that OE just didn't want to guess, and
just took the maximum line length as the maximum entry length.

> However, OE doesn't do this with the "References" line and eventually you
> can't post in a long thread when you get the "line too long" error.

Although I do not directly agree with your "doesn't do" conclusion, thanks
for bringing that problem up. Now lets hope I remember the why of it when
it ever happens . :-)

But even if OE can't deal with header entries it itself pushes over that
1000 chars, how hard would it have been to catch the "line too long"
situation and than just chop one or more entries off of the start of the
line and try again ? Not really rocket science ...

Regards,
Rudy Wieser

[Apd]

"R.Wieser" wrote:
> Apd,
>>| An attempt should be made to include a reasonable number of
>>| backwards references.
>
> :-) Although that /looks/ very helpfull, that "2.2.5. References"
> chapter the above is part of does not give any specifics.

Yes, the RFCs don't spell it out. Note 1036 has been superseded by
5536 which doesn't even mention the "reasonable number". Probably the
best desscription you'll get is from RFC 5322 section 3.6.4.

> Also, this RFC 1036 does not say anything about the order in which the
> entries are supposed to appear - which was specified in RFC 850 which it
> supposedly obsoletes.

RFC 5322 (Internet Message Format) gives an example in Appendix A.2
(Reply Messages) which shows the order.

> There is another explanation, one which has got nothing to do with folding :
> the total length of a header entry seems to be undefined (not in any of the
> RFCs you named).

See RFC 5536 (Netnews Article Format) section 2.2:
| Compliant software MUST NOT generate (but MAY accept) header field
| lines of more than 998 octets. This is the only limit on the
| length of a header field line prescribed by this standard.

> But even if OE can't deal with header entries it itself pushes over that
> 1000 chars, how hard would it have been to catch the "line too long"
> situation and than just chop one or more entries off of the start of the
> line and try again ? Not really rocket science ...

It has to be a bug or an oversight.

[R.Wieser]

Apd,

> Yes, the RFCs don't spell it out.

Which is funny, as they have no problem with precisely describe how to read
the document - including defining the meaning of a slew of symbols in it,
using multiple pages.

>> Also, this RFC 1036 does not say anything about the order in which
>> the entries are supposed to appear - which was specified in RFC 850
>> which it supposedly obsoletes.
>
> RFC 5322 (Internet Message Format) gives an example in Appendix
> A.2 (Reply Messages) which shows the order.

:-) I've had no problem with finding heaps of examples (ctrl-F3 in OE shows
the raw message) and determing the order from just looking at a few of them.
But looking at them as well as in the RFC *still forces me to assume* that
what (I think) I see is what I'm supposed to be doing. :-|

But did you spot the part in RFC 5322 page 26 saying :
[quote]
Note: Some implementations parse the "References:" field to display the
"thread of the discussion".
[/quote]
?
Nicely put, "some" Most newsgrouop readers are older than that 2009 RFC.

As for the order of the message-ids ? The RFC 1036 from 1987 specified it
in chapter 2.2.5.
[quote]
the follow-up message should have a "References" line containing the text of
the original "References" line, a blank, and the Message-ID of the original
message.
[/quote]
Phew! , my observation that the last entry the is the direct parent seems to
have been right :-)

Alas, RFC 5536 supercedes it and (also) forgets to mention anything about
it.

:-( I thought I could read RFCs to get some specifics about a certain
subject. But the more RFCs I read the less info I seem to be left with.
Can't say I like it.

> See RFC 5536 (Netnews Article Format) section 2.2:
> | Compliant software MUST NOT generate (but MAY accept)
> | header field lines of more than 998 octets. This is the only limit
> | on the length of a header field line prescribed by this standard.

Now the only problem is, what /is/ a "header field line" ?

I assumed it would be one of those "folds" you spoke of. Something that
gets strengthened by the part just below what you quoted :
[quote]
NOTE: As stated in [RFC5322], there is NO restriction on the number of lines
into which a header field may be split, and hence there is NO restriction on
the total length of a header field (in particular it may, by suitable
folding, be made to exceed the 998-octet restriction pertaining to a single
header field line).
[/quote]

It answers one question - the "References" header may be longer than a 1000
chars - but doesn't say /anything/ about a limit, or even a "best practices"
value.

IOW, I still have to decide for myself (just as the writers of OE had to)
what a sensible size could/would be.

As for the choice OE made ? They have not done half bad, as I've never, in
all my years using OE, encountered a newsgroup message which crashed it
because of a too-long "References" header.

> It has to be a bug or an oversight.

What are the other possibilities ? On purpose ? :-p

Whoops. Maybe it is. They just might have considered a 20...30 message
deep(!) thread as something that would not ever happen. Ha, the joke is on
them !

Hmmm... I just noticed that RFC 5322 is about mail, not news ...

Regards,
Rudy Wieser

[Apd]

"R.Wieser" wrote:

[...]

> But did you spot the part in RFC 5322 page 26 saying :
> [quote]
> Note: Some implementations parse the "References:" field to display the
> "thread of the discussion".
> [/quote]
> ?
> Nicely put, "some" Most newsgrouop readers are older than that 2009 RFC.

And RFCs tend to standardise what is already common practice. You'll
see "current practice" mentioned in the first paragraph of 5536.

> As for the order of the message-ids ? The RFC 1036 from 1987 specified it
> in chapter 2.2.5.
> [quote]
> the follow-up message should have a "References" line containing the text of
> the original "References" line, a blank, and the Message-ID of the original
> message.
> [/quote]
> Phew! , my observation that the last entry the is the direct parent seems to
> have been right :-)
>
> Alas, RFC 5536 supercedes it and (also) forgets to mention anything about
> it.

I guess 5536 is content to use what 5322 (3.6.4) says about it.

> :-( I thought I could read RFCs to get some specifics about a certain
> subject. But the more RFCs I read the less info I seem to be left with.
> Can't say I like it.

I often find them confusing. Some are better than others.

>> See RFC 5536 (Netnews Article Format) section 2.2:
>> | Compliant software MUST NOT generate (but MAY accept)
>> | header field lines of more than 998 octets. This is the only limit
>> | on the length of a header field line prescribed by this standard.
>
> Now the only problem is, what /is/ a "header field line" ?
>
> I assumed it would be one of those "folds" you spoke of. Something that
> gets strengthened by the part just below what you quoted :

I read it as one line of text in the header, whether it be part of a
fold or not.

> It answers one question - the "References" header may be longer than a 1000
> chars - but doesn't say /anything/ about a limit, or even a "best practices"
> value.

Perhaps there's no need. If it becomes an issue, no doubt we'll see
another RFC. In practice, I've seen no more than around 20 folded ref
lines of about 78 chars max (another recommended limit somewhere).

> IOW, I still have to decide for myself (just as the writers of OE had to)
> what a sensible size could/would be.

Yep.

> As for the choice OE made ? They have not done half bad, as I've never, in
> all my years using OE, encountered a newsgroup message which crashed it
> because of a too-long "References" header.

It doesn't crash but prevents the message from going out. I often see
the error. It will depend on the groups you inhabit. Some threads get
long when a subject changes and a new thread is not started.

> Hmmm... I just noticed that RFC 5322 is about mail, not news ...

Internet messages have a common ancestry. RFC 5536 mentions 5322 a lot.
See appendix C:

| The Netnews article format is a strict subset of the Internet Message
| Format; all Netnews articles conform to the syntax of [RFC5322].

[R.Wieser]

Apd,

> And RFCs tend to standardise what is already common practice.

I've heard that mention a few times. But if thats so than they could have
done a better better job on the "References" header - as *most* newsgroup
readers where, at the time of that document, GUI driven and used that header
to be able to display the messages in a tree form.

> I guess 5536 is content to use what 5322 (3.6.4) says about it.

I just (again) read that part, and noticed something I didn't before :
[quote]
The "References:" field will contain the contents of the parent's
"References:" field (if any) followed by the contents of the parent's
"Message-ID:" field (if any).
[/quote]

That seems to answers two questions: the order of the message-ids inside the
"References" header, and how big it can become :

1) It starts with the initial post and ends with the parent of the current
post.

-ergo-

2) Its size is whatever it takes to store that full lineage (removal is not
premitted).

Than again, looking at the few RFCs you've mentioned, its possible that some
others stuff about it may be strewn elsewhere - and might contradict the
above (just a few lines down is the part about multi-parented messages)

Did I already mention that the RFCs are not as helpfull as I imagined they
would be ? :-)

>> I assumed it would be one of those "folds" you spoke of. Something
>> that gets strengthened by the part just below what you quoted :
>
> I read it as one line of text in the header, whether it be part of a
> fold or not.

:-) I didn't want to use "line", as it could easily mean the total length of
a(n unfolded) header entry as well as what you are referring to in the
above. So I used "a fold" to mean to describe the same as what you did.
It looks like it didn't work out that well. :-\

> Perhaps there's no need. If it becomes an issue, no doubt we'll
> see another RFC.

I might cerainly hope so, as the above-mentioned "whatever its size is"
approach isn't the way to go (as far as I'm concerned)

> In practice, I've seen no more than around 20 folded ref lines of
> about 78 chars max (another recommended limit somewhere).

I did check this newsgroup (to see what would happen on overflow), but the
deepest thread I found was just 23 parents, ~840 chars long.

> It doesn't crash but prevents the message from going out.

Thats ofcourse not something you expect to happen.

> I often see the error. It will depend on the groups you inhabit. Some
> threads get long when a subject changes and a new thread is not started.

I have never encountered the problem. Probably because the newsgroups I
frequent are mostly about technical stuff where threads seldom become long
(and if they do its likely I do not follow them anymore).

> Internet messages have a common ancestry. RFC 5536 mentions 5322
> a lot. See appendix C:
>
> | The Netnews article format is a strict subset of the Internet Message
> | Format; all Netnews articles conform to the syntax of [RFC5322].

Somehow I missed that. Don't know how though, as its referred to all over
the RFC 5536 document ...

Regards,
Rudy Wieser

[J. P. Gilliver (John)]

On Wed, 21 Jul 2021 at 12:37:11, R.Wieser <add...@not.available> wrote

(my responses usually follow points raised):
>John,

Hello.
[]

>What I *did* say that it would be impossible to inherit anything from a
>deleted (parent) post - including its "killfiled" status.

If a post has been deleted, yes, obviously you can't get anything
_directly_ from it.

But in a thread of posts A->B->C, the References: header of B will
contain something from A, and that for C will almost certainly contain
something from both A and B. You are correct that B and C will not
contain anything that indicates A has been deleted: they are generated
by people who don't know that _you_ have deleted A. But your email
client may be able to kill on the presence, in B and C's References:
header, of the part from A.

>
>As for how that works for a reply-to-a-reply to a killfiled post ? I did
>not even go there, as the very same applies there.

Depends on how your email client parses the References header, and
possibly on what sort of kill you specified. If, on seeing post A, you
told your client to "kill thread", I would expect it to note the MID of
A, and kill any subsequent post containing that MID. If you told your
client to "kill author and threads started (or contributed to) by that
author", then ideally whenever it identifies a message as being by that
author, it should kill it but first note its MID, subsequently killing
those threads as above.

>
>> I pointed out that the References header (note the "s") often contained
>> several entries, not just that relating to the immediately-preceding post.
>
>To which I replied that you could have read in the post you replied to
>there - and you even quoted! - that both apd and myself are well aware of
>that header and what its contents are.

Well, you don't seem to see what I've explained above about how
kilfiling on those contents.

>
>You also dropped that tidbit into the discussion without giving any hint to
>why that would be important (you did in your current reply though, see
>further down).
>
>Nonetheless, I tried to explain in my reply, by using the grandparent of a
>post as an example, why that would not work. Alas, not even a hint that
>you read it. Sometimess I ask myself : why do I still bother ?

I ask myself the same question too sometimes.

>
>> It depends how your newsreader killfile processing handles the References
>> header,
>
>That is answered by what this subthread started with. No need to bring it
>up again.
>
>> If it can do a "contains", then it can.
>
>Explain please : Where do you get that message-id (to use into the
>"References" header) for that "contains" action ? Or more specific :
>/how do you know which message-id to use/ ?

When the client detects a post by the disliked author, it could note
that post's MID before deleting that post. (Obviously it may have a
limited space to store MIDs it's looking for; there would be lots of
ways it could decide when to purge older ones.)

>
>Also, have you ever thought about the possibility to un-killfile a subthread
>a bit lower down ? That won't be possible with your method.

If I've killed a subthread, meaning I don't see posts in it, how would I
see one to decide to un-killfile it?

>
>Furthermore, if the "References" header contains the message-id's for the
>/whole/ thread than that approach will kill /all/ replies into that thread,
>regardless of if they where in the killfiled posters subthread or not ...

A->B->C->D
\ If you killed starting at C, E and F would not contain
E->F the MID of C, so the E->F subthread would not be killed
>
>Regards,
>Rudy Wieser
>
>
John

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

At the age of 7, Julia Elizabeth Wells could sing notes only dogs could hear.

[R.Wieser]

John,

> C will almost certainly contain something from both A and B.

True. As defined by one of the RFCs it even has to. But again : relevance.

I already tried to explain how C knowing something of its grandfather A
doesn't help much, if at all. As of yet you still have to respond to it ...

> You are correct that B and C will not contain anything that
> indicates A has been deleted:

Maybe you should start with explaining why you are focussing on a
grandparent and not the parent.

> they are generated by people who don't know that _you_
> have deleted A

Relevance ? What would change if I told them ?

You obviously are trying to make a point there, but I have no idea what it
might be. :-\

> But your email client may be able to kill on the presence, in B
> and C's References: header, of the part from A.

You already said that, and I asked you to explain where you got that A from,
but more importantly : what is the reason you are checking for it. You must
have one, right ?

> I would expect it to note the MID of A

Finally! The explanation where that message-id of A could be coming from.
It took you a while.


To bad though that your "expect it" was already addressed a bit earlier,
where Apd stated that Ethernal September deletes HTMLed messages (your
newsgroup reader has nothing to note) and that I explicitily mentioned that
OE deletes posts by killfiled persons - *all of it*.

Mind you, you are ofcourse free to come up with something that would solve
that problem, but than I expect a bit more than a vague "but there is more
in there than just the direct parent" blurb.

Hint: humans cannot seem to mind read. Assuming they will do so
nonetheless seldom ends well.

> Well, you don't seem to see what I've explained above about
> how kilfiling on those contents.

There seems to be some words missing from that sentence. A conclusion
perhaps ?

As for you thinking that I do not see your explanation ? Maybe thats
because I saw that, within the confines of what hat already been talked
about (by us and you), your explanation didn't go anywhere - and I tried to
make you aware of that without spoonfeeding you the whole dinner.

... Its only in your current post you told us that you take it for granted
that every newsgroup reader has list of those killfiled MIDs
(nonwithstanding me giving no indication that OE has anything of the kind)

> When the client detects a post by the disliked author, it could note
> that post's MID before deleting that post.

... but ok, lets go with that.

That however begs another question : what than was your below quote all
about ?
[quote]

I'm sure I've seen (I think "References") headers that contain references to
the entire thread (or at least as much of it as the previous post retained)

[/quote]

If the reader has a list of killfiled MIDs somewhere, why would I than need
any but the last MID in the References header - the one of the direct parent
? All you would need to do is to check if its in that list of killfiled
MIDs (not the other way around) and you would be done. Why than would you
be needing a grandparent-or-up MID ?

> If I've killed a subthread, meaning I don't see posts in it, how
> would I see one to decide to un-killfile it?

Hint : do you have, for your email, a "junk" folder ?

That you do not see those killfiled posts does not automatically mean that
they are deleted, they can just be given a "hidden" flag. And on OE I can
simply toggle a switch which allows me to view hidden posts too.

> A->B->C->D
> \ If you killed starting at C, E and F would not contain
> E->F the MID of C, so the E->F subthread would not be killed

Yeah, I (re-)realized that the References header only contains the direct
lineage, nothing more. I posted about that an hour and a half later. I
made a mistake an fessed up to it. Big deal.

Regards,
Rudy Wieser

[Apd]

"R.Wieser" wrote:
> Apd,

>> I guess 5536 is content to use what 5322 (3.6.4) says about it.
>
> I just (again) read that part, and noticed something I didn't before :
> [quote]
> The "References:" field will contain the contents of the parent's
> "References:" field (if any) followed by the contents of the parent's
> "Message-ID:" field (if any).
> [/quote]
>
> That seems to answers two questions: the order of the message-ids inside the
> "References" header, and how big it can become :
>
> 1) It starts with the initial post and ends with the parent of the current
> post.
>
> -ergo-
>
> 2) Its size is whatever it takes to store that full lineage (removal is not
> premitted).
>
> Than again, looking at the few RFCs you've mentioned, its possible that some
> others stuff about it may be strewn elsewhere - and might contradict the
> above (just a few lines down is the part about multi-parented messages)

As you say, it's a matter of finding strewn info. I've now remembered
the "internet draft to be" that never was, informally referred to as
"son of 1036". It became a de-facto standard and was encapsulated in
RFC 1849 but only to acknowledge its historic significance.

Section 6.5 tells you all about how the "references" header should
(not) be shortened. I've observed that some newsreaders follow the
recommendations set out in this section.

Thunderbird always folds, keeps the first MID in "references" and
shortens by removing the second after about 30 MIDs. Slrn does similar
(maybe with fewer MIDs). Usenapp, a recent Mac client, keeps only the
minimum, that is the first and last three. Forte Agent 2 does not fold
and shortens by removing the first MID.

So there's varying implementations. I don't know why the SO-1036
recommendations about trimming "references" were not incorporated in
later RFCs.

[Apd]

"Apd" wrote:
> So there's varying implementations. I don't know why the SO-1036
> recommendations about trimming "references" were not incorporated in
> later RFCs.

Scratch that, I've found it!

RFC 5537 (Netnews Architecture and Protocols)
3.4.4. Construction of the References Header Field

| If the resulting References header field would, after unfolding,
| exceed 998 characters in length (including its field name but not the
| final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).
| Trimming means removing any number of message identifiers from its
| content, except that the first message identifier and the last two
| MUST NOT be removed.

[R.Wieser]

Apd,

> As you say, it's a matter of finding strewn info.

And thats not funny, /definitily/ *not* funny. :-\

> I've now remembered the "internet draft to be" that never was,
> informally referred to as "son of 1036". It became a de-facto
> standard and was encapsulated in RFC 1849 but only to
> acknowledge its historic significance.
>
> Section 6.5 tells you all about how the "references" header
> should (not) be shortened.

Thanks for that RFC. And if you do not mind me saying so, it, with its
"notes" and "unresolved issues" is quite a bit more informative than (at
least) 5536.

> Thunderbird always folds, keeps the first MID in "references"
> and shortens by removing the second after about 30 MIDs.

Keeping the first MID makes sense, as it binds all the posts of
subject/thread together - even when all that still exists in the newsgroup
(due to rentention time-outs) is last few branches and the leaves of the
tree.

> So there's varying implementations.

And I really can't imagine to what could have caused that ... :-p

> I don't know why the SO-1036 recommendations about trimming
> "references" were not incorporated in later RFCs.

Same here. And in regard to that, I find it ... odd that such references,
when they are available, are tucked away in a chapter somewhere at the end
of the document (instead of directly in/below the paragraph pertaining to
the subject). Oh well.

> Scratch that, I've found it!
>
> RFC 5537 (Netnews Architecture and Protocols)
> 3.4.4. Construction of the References Header Field
>
| If the resulting References header field would, after unfolding,

[snip]

Well, couldn't they just have said that in RFC 850 ? :-)

But yes, that makes sense as the "absolute minimum" requirements. And they
are rather clear about it too. Me likey.

I also thought of checking that "son of 1036" for the maximum length of a
message-id (I did seach for, but never found it). Its 250 octets, which
means that no matter how bad the weather gets those three easily fit within
that "References" headers 1000 chars.

Ofcourse, the choice for just three message-ids as a minimum could well have
been caused by the fact that four of them, with the current spacing rules,
simply would not have fit. :-)

Thanks for putting the effort into finding all that info you posted. I
appreciate it.

Regards,
Rudy Wieser

[J. P. Gilliver (John)]

On Sat, 24 Jul 2021 at 12:41:01, R.Wieser <add...@not.available> wrote

(my responses usually follow points raised):
>John,

(Rudy, nobody else starts posts like that. I think I see why you do it,
but it could be misconstrued.)

>
>> C will almost certainly contain something from both A and B.
>
>True. As defined by one of the RFCs it even has to. But again : relevance.

I thought I had, but will again:

If people kill a post, they don't want to see its contents. With the
atrocious lack of snipping that is the norm these days, it is highly
likely that a significant part of the unwanted post will remain, not
only in the first followup, but subsequent followups.

>
>I already tried to explain how C knowing something of its grandfather A
>doesn't help much, if at all. As of yet you still have to respond to it ...

I'm trying to. Again.

>
>> You are correct that B and C will not contain anything that
>> indicates A has been deleted:
>
>Maybe you should start with explaining why you are focussing on a
>grandparent and not the parent.

See above.

>
>> they are generated by people who don't know that _you_
>> have deleted A
>
>Relevance ? What would change if I told them ?

Nothing. I wasn't sure why you said that you can't retrieve anything
from a deleted post, including the fact that it had been deleted; that
is true, but I couldn't see why you thought it was important.

>
>You obviously are trying to make a point there, but I have no idea what it
>might be. :-\
>
>> But your email client may be able to kill on the presence, in B
>> and C's References: header, of the part from A.
>
>You already said that, and I asked you to explain where you got that A from,
>but more importantly : what is the reason you are checking for it. You must
>have one, right ?

See above.

>
>> I would expect it to note the MID of A
>
>Finally! The explanation where that message-id of A could be coming from.
>It took you a while.
>

To use your own words, "I tried to make you aware of that without
spoonfeeding you the whole dinner" - but maybe I should have, if you're
going to make sarky comments like "Finally!".

>
>To bad though that your "expect it" was already addressed a bit earlier,
>where Apd stated that Ethernal September deletes HTMLed messages (your
>newsgroup reader has nothing to note) and that I explicitily mentioned that
>OE deletes posts by killfiled persons - *all of it*.

Neither of those would stop you seeing followups by others (in the first
case, using other servers) that _quoted_ some of the HTML-eejit posts.

>
>Mind you, you are ofcourse free to come up with something that would solve
>that problem, but than I expect a bit more than a vague "but there is more
>in there than just the direct parent" blurb.

We're obviously not understanding each other again: I don't understand
why you're only interested in a post's direct parent, and you don't
understand why I'm interested in further back. I _hope_ I've explained
above.

>
>Hint: humans cannot seem to mind read. Assuming they will do so
>nonetheless seldom ends well.

It's a fine line between "spoonfeeding" and assuming. Everybody -
including you and me - have erred on both sides of that line.

>
>> Well, you don't seem to see what I've explained above about
>> how kilfiling on those contents.
>
>There seems to be some words missing from that sentence. A conclusion
>perhaps ?

Yes, I realised as soon as I read my post that I'd written a
non-sentence. I can't now remember what I intended!

>
>As for you thinking that I do not see your explanation ? Maybe thats
>because I saw that, within the confines of what hat already been talked
>about (by us and you), your explanation didn't go anywhere - and I tried to
>make you aware of that without spoonfeeding you the whole dinner.

Ditto (-:

>
>... Its only in your current post you told us that you take it for granted
>that every newsgroup reader has list of those killfiled MIDs
>(nonwithstanding me giving no indication that OE has anything of the kind)

I don't know whether newsreaders do that; I rather suspect they don't,
actually. I do know that I can kill (actually "Mark Uninteresting") a
thread in my newsreader; I don't know how it identifies which posts not
to present to me, but it does work - and it doesn't do it by subject,
because if someone starts a new thread with the same Subject, I _do_ see
it. (My newsreader can split threads when they've forked - or, at least,
I can tell it to do so - and I _think_ I can tell it to mark only one
branch as uninteresting; I don't think I've ever done so, as the
procedure for telling it to split is slightly tedious.)

>
>> When the client detects a post by the disliked author, it could note
>> that post's MID before deleting that post.
>
>... but ok, lets go with that.
>
>That however begs another question : what than was your below quote all
>about ?
>[quote]
>I'm sure I've seen (I think "References") headers that contain references to
>the entire thread (or at least as much of it as the previous post retained)
>[/quote]

If I want not to see _any_ descendant of a post, I need (my newsreader
to) have some way of knowing that a post is such a descendant. Other
than subject (which can be changed anyway).

>
>If the reader has a list of killfiled MIDs somewhere, why would I than need
>any but the last MID in the References header - the one of the direct parent
>? All you would need to do is to check if its in that list of killfiled
>MIDs (not the other way around) and you would be done. Why than would you
>be needing a grandparent-or-up MID ?

A->B->C

I've killed A, so don't want to see B or C. B comes in - by your method,
it could be killed because it's "parent" is A. Now C comes in. Its
parent is B, which has been hidden (or C might even arrive before B);
C's parent is B, so just looking at the parent, the newsreader would not
know to hide it - but if it looks at all C's ancestors, it would. [Is
that spoonfed enough for you (-:?]

As I've said, I don't know if my - or any other - newsreader _does_
implement hiding of thread posts by using the MIDs in the References:
header, but now you've made me think about it, I can't think of any
other way (other than by subject, and I've already said why it doesn't
use that); suggestions?

>
>> If I've killed a subthread, meaning I don't see posts in it, how
>> would I see one to decide to un-killfile it?
>
>Hint : do you have, for your email, a "junk" folder ?

Yes. (Well, somewhere all email for addresses I haven't specifically
routed goes; I don't have a specific "junk" or "spam" folder, as I
receive so little of those that I don't need one.) But the decision to
look in a junk/spam _email_ folder is usually prompted by an expectation
of having received an email and wondering where it's gone; if I've
marked a _news_ thread as uninteresting, I can't think why I might
suddenly decide I want to see (posts in) it again.

>
>That you do not see those killfiled posts does not automatically mean that
>they are deleted, they can just be given a "hidden" flag. And on OE I can
>simply toggle a switch which allows me to view hidden posts too.

My newsreader discards posts a given number of days (default 3, and this
'group is still at that) after downloading them, and I think I've had
threads remain "uninteresting" longer than that.

>
>> A->B->C->D
>> \ If you killed starting at C, E and F would not contain
>> E->F the MID of C, so the E->F subthread would not be killed
>
>Yeah, I (re-)realized that the References header only contains the direct
>lineage, nothing more. I posted about that an hour and a half later. I
>made a mistake an fessed up to it. Big deal.
>
>Regards,
>Rudy Wieser
>

(I too have made a mistake in this thread - I used the word "mail"
instead of "news" at one point in one post. I thought of posting a
correction, but thought it would cause more confusion than it cured.)

>
>
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Don't play "stupid" with me... I'm better at it.

[Apd]

"R.Wieser" wrote:

> Thanks for putting the effort into finding all that info you posted. I
> appreciate it.

You're very welcome. I didn't know about preserving the first MID so
now I'll do that when manually trimming the refs. You piqued my
interest and I've also learnt something. Ain't Usenet wonderful?!

[R.Wieser]

John,

> I thought I had, but will again:
>
> If people kill a post, they don't want to see its contents.

Agreed.

> With the atrocious lack of snipping that is the norm these days, it is
> highly likely that a significant part of the unwanted post will remain,
> not only in the first followup, but subsequent followups.

Is that *all* you have to say ? No problem definition of any kind ? And
expect me to figure out what you might be meaning regardless ? Really ?

And pardon me, the above is written as if you are suggesting that replies to
a killfiled post should be killfiled too. Which is what Apd and myself
where already past when you posted your first reply.

Worse, apd quoted my explanation of how to hide such a subtree as part of
fixing OEs "lets just delete the message of a the killfiled posters "
behaviour.

>>I already tried to explain how C knowing something of its grandfather A
>>doesn't help much, if at all. As of yet you still have to respond to it
>>...
>
> I'm trying to. Again.

No, you're not trying at all. Upto this point in your post you have only
offerered a couple of statements, but no explaining of any kind.

>>> You are correct that B and C will not contain anything that
>>> indicates A has been deleted:
>>
>>Maybe you should start with explaining why you are focussing on a
>>grandparent and not the parent.
>
> See above.

Bullshit. You have not even *started* to explain anything.

>>Relevance ? What would change if I told them ?
>
> Nothing. I wasn't sure why you said that you can't retrieve anything from
> a deleted post,

Well, are you now ?

> including the fact that it had been deleted;

:-) I never said, or implicated anything like that. Because I can, in
the context of this thread, easily do that. (think about it).

> that is true, but I couldn't see why you thought it was important.

That probably is because you barged into this thread without even bothering
to understand what apd and myself where talking about. :-(

The question is, do you understand it *now* ?

>>You already said that, and I asked you to explain where you got that A
>>from, but more importantly : what is the reason you are checking for it.
>>You must have one, right ?
>
> See above.

You *still* have not even begun to explain anything to me. So again,
bullshit.

>>Finally! The explanation where that message-id of A could be coming
>>from. It took you a while.
>
>To use your own words, "I tried to make you aware of that without
>spoonfeeding you the whole dinner" - but maybe I should have, if you're
>going to make sarky comments like "Finally!".

Finally, finally, finally! Is that enough to get you to actually explain
yourself ?

From my POV you have been, *and are still trying* your hardest *not* to
explain anything to me, and I had to fight to even get that "I would expect
it to note the MID of A" statement outof you.

>>To bad though that your "expect it" was already addressed a bit earlier,
>>where Apd stated that Ethernal September deletes HTMLed messages (your
>>newsgroup reader has nothing to note) and that I explicitily mentioned
>>that OE deletes posts by killfiled persons - *all of it*.
>
>Neither of those would stop you seeing followups by others (in the first
>case, using other servers) that _quoted_ some of the HTML-eejit posts.

You MUST be trolling, as the problem you quoted is the polar opposite of
what you wrote.

>>Mind you, you are ofcourse free to come up with something that would solve
>>that problem, but than I expect a bit more than a vague "but there is more
>>in there than just the direct parent" blurb.
>
>We're obviously not understanding each other again:

No, I think I have a pretty good idea to why you do not understand me, but
no matter what or how I try to explain it I can't seem to get thru to you.
:-(

> I don't understand why you're only interested in a post's direct parent,

I'm returning the question : Why should I be interrested in the grandparent
? Answer that one and you have most, if not all of your answer.

> and you don't understand why I'm interested in further back.

Are you interrested in further back ? I think they make great music.
Have you already heard their latest song ? Its certainly has a catchy tune,
don't you think ?

All jokes aside, even if I change that "why" into a "what" that line is
devoid of any meaning. Purposely or just because you just can't help it.

> I _hope_ I've explained above.

Lol! (thats a "no").

>>Hint: humans cannot seem to mind read. Assuming they will do so
>>nonetheless seldom ends well.
>
> It's a fine line between "spoonfeeding" and assuming.

Lol. My "troll" meter just went up a number. Comparing apples to eggs
does that.

>> As for you thinking that I do not see your explanation ? Maybe thats
>> because I saw that, within the confines of what hat already been talked
>> about (by us and you), your explanation didn't go anywhere - and I tried
>> to make you aware of that without spoonfeeding you the whole dinner.
>
>Ditto (-:

Bullshit. You have only talked about your own idea (checking the
grandparent or with aid of a special list), without even /trying/ to hint to
why that would be needed / why the parent could not be used. Not there,
not anywhere.

>>... Its only in your current post you told us that you take it for granted
>>that every newsgroup reader has list of those killfiled MIDs
>>(nonwithstanding me giving no indication that OE has anything of the kind)
>
>I don't know whether newsreaders do that; I rather suspect they don't,
>actually. I do know that I can kill (actually "Mark Uninteresting") a
>thread in my newsreader;

And that last part is exactly the mechanism I've been describing in the
grandparent of your initial post to what I changed OEs "delete the message"
killfile action into ....

>I don't know how it identifies which posts not to present to me, but it
>does work

Again, look up "inheritance".

> I don't think I've ever done so, as the procedure for telling it to split
> is slightly tedious.)

In OE you just click the "ignored" icon. Easy as pie.

>>That however begs another question : what than was your below quote all
>>about

[snip quote]

>
>If I want not to see _any_ descendant of a post, I need (my newsreader to)
>have some way of knowing that a post is such a descendant.

Again, check out "inheritance".

Simply put: My father inherited his looks from my grandfather. I than
inherited my looks from my father. I did not need my grandfather for that
in any way. And thats good, because my grandfather died even before I was
born. :-)

Again: as long as the parent is available I could not care less about any of
the other ancestors. The above is why.

Besides, I already explained that looking at the grandfather to determine to
hide a post could easily ignore that the direct parent isn't hidden
anymore - and thus the reply to it should not be either.

> I've killed A, so don't want to see B or C.

A problem here is that you use "killed" and "hidden" interchangable, which
confuses the matter.

I'm going to use "killed" as meaning "the message is flagged as killed,
causing the browser to hide it". Also, I'm going to assume that both checks
are done only once, when a post is stored the first time. If you where
thinking of something else feel free to specify it.

> B comes in - by your method, it could be killed because it's "parent" is
> A.

Agreed. B is killed to.

> Now C comes in. Its parent is B, which has been hidden

Nope. B is killed.

> (or C might even arrive before B);

Thats a problem we could put another discussion up for. For the moment
lets just stay with the simple stuff.

> C's parent is B, so just looking at the parent, the newsreader would not
> know to hide it

Yes it would know. B is (marked as) killed, which is something C can see
and as a result mark itself as killed too. Simple inheritance.

> but now you've made me think about it, I can't think of any other way
> (other than by subject, and I've already said why it doesn't use that);
> suggestions?

I'm sorry, which subject would that be and where did you "already said why
it doesn't use that" (quote please. include post datestamp as well).

Currently I've got no idea what you are talking about for both, so I can't
make any suggestions either.

>>Hint : do you have, for your email, a "junk" folder ?
>

>Yes. .... I can't think why I might suddenly decide I want to see (posts
>in) it again.

Don't mix up the example with what its ment to explain. Seldom works well.

> But the decision to look in a junk/spam _email_ folder is usually prompted
> by an expectation of having received an email and wondering where it's
> gone

There you have one reason, and there are more. But the point is, you /can/
look thru it. None of the messages have been deleted, they have just been
hidden from casual view.

Regards,
Rudy Wieser

[J. P. Gilliver (John)]

On Sat, 24 Jul 2021 at 22:14:06, R.Wieser <add...@not.available> wrote

(my responses usually follow points raised):
>John,

[]

>Is that *all* you have to say ? No problem definition of any kind ? And
>expect me to figure out what you might be meaning regardless ? Really ?

[]

>> I'm trying to. Again.
>
>No, you're not trying at all. Upto this point in your post you have only
>offerered a couple of statements, but no explaining of any kind.

[]

>Bullshit. You have not even *started* to explain anything.

[]

>That probably is because you barged into this thread without even bothering
>to understand what apd and myself where talking about. :-(

[]

>You *still* have not even begun to explain anything to me. So again,
>bullshit.

[]

>Finally, finally, finally! Is that enough to get you to actually explain
>yourself ?
>
>From my POV you have been, *and are still trying* your hardest *not* to
>explain anything to me, and I had to fight to even get that "I would expect
>it to note the MID of A" statement outof you.

[]
My patience with your rudeness has expired.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

You cannot simply assume someone is honest just because they are not an MP.

[R.Wieser]

John,

> My patience with your rudeness has expired.

No problem. As you might have noticed from my "bulllshit" remarks my
patience in regard to your claims of having explained stuff when you did no
such thing had become very thin too.

From my POV I've done my stinking best to explain how the inheritence method
works, and that multiple times. Did you ever acknowledge that in any way ?
Even just with a request for more explanation of a particular point or by
challenging a certain aspect ?

Ah, don't make me laugh. All you have done is do ignore all my attempts in
that direction. Not a word about any of it.. :-(

And you know whats the worst of it ? Most of what you had / still have
problems with *was already mentioned/explained before you even posted your
first reply*. Which I tried to refer you to multiple times.

Any response to that ? Ha, don't make me laugh!

No, I did not enjoy our conversation /at all/. From the start it was
rather clear that you had your idea, and that was the only thing that
mattered to you. Apd and myself where talking about something else ? Meh,
who cares!

Regards,
Rudy Wieser

[AK]

On Saturday, July 17, 2021 at 3:37:36 AM UTC-5, R.Wieser wrote:
> Jolly,
> > Same to you, you brainwashed officious twit !
> Just put him into your killfile.
>
> You know, its rather amusing to see the hypocrisy with which GG complains
> about "crap links". Absolutitly *none* of the subjects he has posted has
> anything to do with XP [1], and his links are therefore absolutily worthless
> to anyone here.
>
> [1] from 45 he started last six months most are about Win 10 or related,
> quiete a number about non-computer stuff (ufos, argentinians, gaza city,
> biden, cancel culture, amazon, twitter, etc) and /not a single one/ about
> XP.
>
> Also, most of all of those subjects he posted were pretty-much copy-pasted
> from news sites.
>
> His demands that we all read his posts as HTML but first have to ask his
> permission to do so is just the cherry on top.
>
> Regards,
> Rudy Wieser
With the language that GG uses, GG is not an accurate name.

:-)

[R.Wieser]

AK,

> With the language that GG uses, GG is not an accurate name.

Always be weary of people who refer to/name themselves using positive
attributes.

The same goes for negative attributes, but you need to be less weary. :-)

Regards,
Rudy Wieser

[R.Wieser]

John,

Just to finish it off :

Looking back without the distraction of trying to explain stuff to you (your
own and mine), I noticed something odd & problematic about your explanation
using A, B and C.

Lets just add messages "@" to the front and "D" and "E" to the end of the
above :

@ -> A -> B -> C -> D -> E

"A" is still the killfiled and deleted post.

-- You've always said that B looks at A, which is mighty odd : Why isn't is
B looking at @, its grandfather ? You never touched, let alone explain
that ...

-- C looks at A, which is its grandfather, which is in line with your "look
at the grandfather" idea. So far, so good.

-- But who is D looking at ? You've been telling us that all of the
to-be-suppressed subthreads messages should be looking at A.

But if that us true than D is looking at its *great*-grandfather, which does
not match your idea at all.

Also, how would D know to look at A, and not at B or even @ ?

-- The same goes for E, it would be looking at its
*great-great*-grandfather, when it, along your idea, should be looking at C
...

IOW, besides the unexplained "B looks at A" oddity, by not looking further
than those A, B and C messages you've robbed yourself of a chance to see how
your approach could become be problematic, or at least would cause more
questions.

Now I think of it, that could even be the reason why you never did post an
example beyond those three ... <whistle>


There is some other odd thing : For some reason you found it logical that
your newsgroup reader would actually delete a killfiled post and store its
MID in a special list, but for some reason the replies to it would just be
hidden. Why ? Why a frankenstein mix of deletion and hiding, and not one
or the other for both ?


And no, I don't expect you to respond.

Regards,
RudyWieser

P.s.
As I've been trashing your initial message (and everything after it too) I'm
pretty-much obliged to give an indication of how it /could/ have looked :

[quote=you, the relevant part]
I'm sure I've seen headers that contain references to the entire thread
[/quote]

[addition, mine]
If your newsgroup reader keeps the MIDs of the killfiled posts somewhere you
could go thru a messages references beginning with the grandparent and see
if its in that list, and if so ignore it.
[/addition]

With that I could have connected the dots from that list all the way down to
that References header.

Ofcourse, I would than have told you that OE does not have such a list and
asked you why you would start with the grandparent and not the parent and
why you would not just delete the replies too, but at least we would be on
the same track there.

[marika]

Got it.

MK5000


An understanding heart is everything is a teacher, and cannot be esteemed highly enough. One looks back with appreciation to the brilliant teachers, but with gratitude to those who touched our human feeling. The curriculum is so much necessary raw material, but warmth is the vital element for the growing plant and for the soul of the child.--Carl Gustav Jung