Read 'em and weep, Win 10 sheeple.year=0&cweid=0&order=1&trc=741&sha=96656e0273b52e8473fbf8b6371fe2ed4a0f8ae8
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&
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
Read 'em and weep, Win 10 sheeple.year=0&cweid=0&order=1&trc=741&sha=96656e0273b52e8473fbf8b6371fe2ed4a0f8ae8
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&
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
On Thu, 15 Jul 2021 20:27:11 -0500, Merle@invalid.com wrote:0&year=0&cweid=0&order=1&trc=741&sha=96656e0273b52e8473fbf8b6371fe2ed4a0f8ae8 >>
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=
cvssscoremax=0&year=0&cweid=0&order=1&trc=2261&sha=41e451b72c2e412c0a1cb8cb1dcfee3d16d51c44Windows 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&
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.
On 16/07/2021 02:27, Merle@invalid.com wrote:
ReadCAN 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.
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.
Same to you, you brainwashed officious twit !
Jolly,
Same to you, you brainwashed officious twit !
Just put him into your killfile.
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
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.
On Sat, 17 Jul 2021 00:06:53 +0700, JJ <jj4public@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.
Jolly,
Same to you, you brainwashed officious twit !
Just put him into your killfile.
"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.
Thankfully, Eternal September rejects HTML posts so I
never see his crap unless someone responds to it.
"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.
No, I ain't complaining about him. I'm complaining about you
people whining
the simplicity of Kill Filtering seems to escape you.
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. :-\
"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.
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. :)
The "References" header will have what you need.
If you can't find the message in OE look it up on Howard Knight:
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. :-\
?
So true. This guy wants to revive Usenet and has a PDF presentation[snip: URL censored]
about it:
On Mon, 19 Jul 2021 03:25:36 +0100, Apd wrote:
So true. This guy wants to revive Usenet and has a PDF presentation[snip: URL censored]
about it:
LOL. Might as well use PowerPoint, and to recommend that Usenet content should be JavaScript... heck, WebAssembly enabled.
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). :-)
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 gather from all that you want to kill the subthreads arising
from killfiled messages.
I didn't know it was even possible in OE.
I wasn't aware Outlook could do NNTP.
always preferring OE which is a different product
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.
"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".
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)
On Mon, 19 Jul 2021 at 11:33:01, R.Wieser <address@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, ...)
[]
I don't think the NNTP design guarantees that the Reference
information is "complete". Merely that every message contains some subset
of all information.
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 ?
No need here. Thankfully, Eternal September rejects HTML posts so I
never see his crap unless someone responds to it.
You people just keep making trolls like him satisfied with your
constant mention of them. They're attention seekers. Kill file them
and that's it. Don't sit around discussing the moron. You're just
feeding him when you do.
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,
If it can do a "contains", then it can.
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 ...
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.
I don't think the NNTP design guarantees that the Reference
information is "complete". Merely that every message contains
some subset of all information.
| 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.
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.
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.
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.
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).
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 ...
Yes, the RFCs don't spell it out.
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.
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.
It has to be a bug or an oversight.
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 :
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.
Hmmm... I just noticed that RFC 5322 is about mail, not news ...
And RFCs tend to standardise what is already common practice.
I guess 5536 is content to use what 5322 (3.6.4) says about it.
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.
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).
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.
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].
John,
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 ...\ If you killed starting at C, E and F would not contain
D
Regards,
Rudy Wieser
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.
I would expect it to note the MID of A
Well, you don't seem to see what I've explained above about
how kilfiling on those contents.
When the client detects a post by the disliked author, it could note
that post's MID before deleting that post.
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?
\ If you killed starting at C, E and F would not containD
E->F the MID of C, so the E->F subthread would not be killed
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)
So there's varying implementations. I don't know why the SO-1036 recommendations about trimming "references" were not incorporated in
later RFCs.
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.
Thunderbird always folds, keeps the first MID in "references"
and shortens by removing the second after about 30 MIDs.
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
Thanks for putting the effort into finding all that info you posted. I appreciate it.
John,(Rudy, nobody else starts posts like that. I think I see why you do it,
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 ?
C
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.
\ If you killed starting at C, E and F would not containD
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 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.
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 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.
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.
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
I don't think I've ever done so, as the procedure for telling it to split
is slightly tedious.)
[snip quote]That however begs another question : what than was your below quote all >>about
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.
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 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?
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.
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
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.
Jolly,With the language that GG uses, GG is not an accurate name.
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.
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,See above.
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 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 478 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 229:34:46 |
| Calls: | 9,528 |
| Files: | 13,646 |
| Messages: | 6,136,179 |