identifying _followups_ to a poster?

Anyone know a way to identify, not only posts from a poster, but
followups to his/her posts? In another 'group and with another poster
looking at the References: header seems to help, but I don't think so in
this case. I'm looking for something that works with just the headers -
obviously if the body contains "Fred said", then I know it's a followup
to Fred, but by then I'm looking at the body anyway.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

After I'm dead I'd rather have people ask why I have no monument than why I
have one. -Cato the Elder, statesman, soldier, and writer (234-149 BCE)

J. P. Gilliver (John) wrote:

Anyone know a way to identify, not only posts from a poster, but
followups to his/her posts? In another 'group and with another poster
looking at the References: header seems to help, but I don't think so
in this case. I'm looking for something that works with just the
headers - obviously if the body contains "Fred said", then I know
it's a followup to Fred, but by then I'm looking at the body anyway.

Use an NNTP client that has the option to hide all posts in a subthread
to a flagged post. When I flag a post as Ignored, an option also marks
all replies under that post as also Ignored. I use a default view of
Hide Ignored Messages. That way, if I need to look at the unwanted
posts, I can switch to the All Messages view. Also, if I delete an
unwanted post, the thread will reappear when someone submits a new reply
to the unwanted post and why I hide instead of delete. Hiding keeps the
posts in my client's message store so it can hide all child posts of a
flagged parent post.

As I recall, Turnpike is an old NNTP client. That's not necessarily a
bad thing since my NNTP client, 40tude Dialog, is also ancient and
abandoned. It's been too long since I last trialed Thunderbird (which
lasted only 6 months before I gave up on it for e-mail and newsgroups)
to remember if it has an option to hide the entire subthread of a
flagged post.

https://support.mozilla.org/en-US/kb/ignore-threads

That has a "Ignore a subthread" section so Thunderbird will apparently
flag an entire subthread under a flagged parent post. However, that
describes how to manually perform the hide of a subthread, not how to
set an option and use rules/filters to hide a parent post and all
replies (child posts) to it. Thunderbird has its Usenet support
community over at ---.
..-------------------'
'--- mozilla.support.thunderbird
(server = news.mozilla.org, port = 119)

Sorry, I don't use Turnpike to know what features it has. Turnpike was
acquired by Demon Internet who then proferred it to their customers. It
has only a small following outside of the Demon Internet customerbase.
For more help with that newsreader, ask in its newsgroup over at ---.
..----------'
'--- demon.ip.support.turnpike

I looked at http://www.plainfaqs.org.uk/six/ufaq.html but did not see
anything regarding filters or watch/hide options, especially on
subthreads (child posts) of a flagged parent post. From its FAQs, look
doubtful Turnpike has the features you need to hide a post and its
entire subthread. If the Turnpike Usenet community is dead, another
place to ask about newsreaders is over at ---.
..--------------------------------------------'
'--- news.software.readers

Be sure to specify "Turnpike" in the Subject so others know which client
you are asking about. I had to look in your headers to see what you
used here to post your inquiry.

In message , VanguardLH
writes:
J. P. Gilliver (John) wrote:
[]
Use an NNTP client that has the option to hide all posts in a subthread
to a flagged post. When I flag a post as Ignored, an option also marks
all replies under that post as also Ignored. I use a default view of
Hide Ignored Messages. That way, if I need to look at the unwanted
posts, I can switch to the All Messages view. Also, if I delete an
unwanted post, the thread will reappear when someone submits a new reply
to the unwanted post and why I hide instead of delete. Hiding keeps the
posts in my client's message store so it can hide all child posts of a
flagged parent post.

As I recall, Turnpike is an old NNTP client. That's not necessarily a
bad thing since my NNTP client, 40tude Dialog, is also ancient and
[]
Yes, I can mark a thread as "uninteresting", which I admit I'd forgotten
in this context. But I'd still have to see one followup post to the
person I'd killfiled to make/mark that thread uninteresting.

Be sure to specify "Turnpike" in the Subject so others know which client
you are asking about. I had to look in your headers to see what you
used here to post your inquiry.

I was wondering about general principles (I'd have asked in the Turnpike
newsgroup, I think, otherwise), to see if anyone could think of anything
header-specific that would identify followups. I hadn't thought of the
_combination_ of headers implied by marking a thread uninteresting;
thanks.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Where [other presenters] tackle the world with a box of watercolours, he
takes a spanner. - David Butcher (on Guy Martin), RT 2015/1/31-2/6

J. P. Gilliver (John) wrote:

Yes, I can mark a thread as "uninteresting", which I admit I'd
forgotten in this context. But I'd still have to see one followup
post to the person I'd killfiled to make/mark that thread
uninteresting.

That's why I said you'll have to investigate the settings within
Turnpike to see if it can apply the flag to all child posts of a parent
post flagged as "uninteresting". If the client cannot do that, there's
nothing you can do to emulate the effect.

Yes, you could define a rule but you would have to do that everytime you
wanted to tag a parent post as unwanted with a rule that looks for the
same Message-ID as the parent listed in the child's References header.
That would be very tedious: find an unwanted post, define a new rule to
add its MID in a regex looking for a blacklist of MIDs in the References
header, and repeat ad nauseum on each new unwanted post. You'll
probably hit some maximum length for the regex string to parse it so you
end up with multiple MIDs-in-References blacklist rules. You really
want an NNTP client that will maintain its MID blacklist for you.

Also, when threads get long, the References header will get truncated.
The starting thread remains listed as the first one in the References
headers but after that the leading MIDs will get removed to make room
for newer trailing MIDs (i.e., FIFO on MID removal except for the very
first MID). So the MID on which your rule checks could disappear from
the References header.

In message , VanguardLH
writes:
J. P. Gilliver (John) wrote:

Yes, I can mark a thread as "uninteresting", which I admit I'd
forgotten in this context. But I'd still have to see one followup
post to the person I'd killfiled to make/mark that thread
uninteresting.

That's why I said you'll have to investigate the settings within
Turnpike to see if it can apply the flag to all child posts of a parent
post flagged as "uninteresting". If the client cannot do that, there's
nothing you can do to emulate the effect.

It does that (when I mark a post/thread as uninteresting, I see no more
posts in that thread). But I still have to see the first one to mark it
as uninteresting: this is the first followup, as I don't see the
original post as that's by the person I've killfiled. In another 'group,
I've been able to set up a rule based on the References header that
stops me seeing any posts by a particular poster _and_ any followups to
that person's posts, but that can't be done here AFAICS - you'll know
why (-:! There probably isn't _any_ way to do that in this case, other
than seeing the first followup and marking the thread uninteresting.

Yes, you could define a rule but you would have to do that everytime you
wanted to tag a parent post as unwanted with a rule that looks for the
same Message-ID as the parent listed in the child's References header.
That would be very tedious: find an unwanted post, define a new rule to
add its MID in a regex looking for a blacklist of MIDs in the References
header, and repeat ad nauseum on each new unwanted post. You'll
probably hit some maximum length for the regex string to parse it so you
end up with multiple MIDs-in-References blacklist rules. You really
want an NNTP client that will maintain its MID blacklist for you.

Fortunately, the "uninteresting" flag in TP does that, I think. (I'm
_assuming_ it discards the rule when all posts in the thread have
expired [I have expiry set to three days in most 'groups], but I don't
know. Maybe I'll ask in the TP 'group!)

Also, when threads get long, the References header will get truncated.

Yes, I've noticed that.

The starting thread remains listed as the first one in the References
headers but after that the leading MIDs will get removed to make room
for newer trailing MIDs (i.e., FIFO on MID removal except for the very
first MID). So the MID on which your rule checks could disappear from
the References header.

Is that just generally what happens, or is it part of some RFC?
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"I'm not against women. Not often enough, anyway." - Groucho Marx

J. P. Gilliver (John) wrote:

In message , VanguardLH
writes:
J. P. Gilliver (John) wrote:

Yes, I can mark a thread as "uninteresting", which I admit I'd
forgotten in this context. But I'd still have to see one followup
post to the person I'd killfiled to make/mark that thread
uninteresting.

That's why I said you'll have to investigate the settings within
Turnpike to see if it can apply the flag to all child posts of a parent
post flagged as "uninteresting". If the client cannot do that, there's
nothing you can do to emulate the effect.

It does that (when I mark a post/thread as uninteresting, I see no more
posts in that thread). But I still have to see the first one to mark it
as uninteresting: this is the first followup, as I don't see the
original post as that's by the person I've killfiled.

Does "killfile" mean you deleted the parent post or you flagged it (and
hidden it)? Deleting means the client may no longer keep track of that
parent post. Presumably you are using a rule or filter to set an
"uninteresting" flag on an unwanted post; else, you'll have to do it
manually on every parent post you don't want to see.

When you say "followup", are you talking about replies or the use of the
FollowUp-To header?

In another 'group,
I've been able to set up a rule based on the References header that
stops me seeing any posts by a particular poster _and_ any followups to
that person's posts,
why (-:! There probably isn't _any_ way to do that in this case, other
than seeing the first followup and marking the thread uninteresting.

The MID header is going to change every time a poster submits an
article. All you can filter out is ONE thread by MID. The next time
the poster submits, their MID will be something different. The only
filtering on MID would eliminate all posts by someone is if that someone
always uses a right-token that remains the same and is never used by
anyone else, like varstring@theirdomain where they registered
theredomain and no one else uses it. I have my NNTP client use a unique
right-token in my MID header but it isn't registered and anyone could
use it, not just me. Someone could attempt to forge my identity and I
couldn't stop them (unless they used the same NNTP provider and I
complained to get their account killed - which obviously works only at
registered NNTP provides).

If they are using a common right-token or they aren't assigning one at
all and letting the NNTP server assign one then you cannot use MID to
filter out all posts by one poster, only one of their posts (and replies
to it by checking the References header). You would need to define a
blacklist rule that lists every MID used in the past and then for the
new articles that show up, something like:

^References: \S*(mid1|mid2|...|midN)

But that list would have to get manually updated by you after you see
their next new post. Doesn't look like Turnpike is working for you
regarding its "uninteresting" flag. If it did, you should be able to
define a rule to identify the *poster* to then set the uninteresting
flag (and recurse that flag onto any child posts). If you don't want to
see the first post by the unwanted poster and any replies to them, you
need to use a rule to set the flag on their parent post and an option in
the client to recurse that flag onto any child posts. Trying to do the
same with rules means you will see their first post (to get their MID)
and then update your rule to hide any child posts all of which is
retroactive since you are doing this yourself after first seeing their
parent post.

Although rules can be defined based on the From header to identify a
poster, the sender can specify what is in that header. It's not like
they logged into an account that forces the account owner's name in the
From header. The sender can claim to be whomever they want. I could
submit a post with a From header that says I'm you. If they use a
unique right-token in their MID header (as I do) then you could filter
on that value (in the MID header and in the References header). If they
are using the MID assigned by their NNTP provider or some common one,
like for Forte Agent, or keep varying the right-token then filtering on
their MID is pointless and you're wasting your time (unless you are
editing the view of message retroactively which is a waste of time).
From and Message-ID are overview headers.

To better filter on unwanted posts (content) or posters, you need to
include the non-overview headers in your filters. However, most NNTP
clients will only retrieve the overview headers. Even if they let you
test using regex on all headers, if they only retrieve overview headers
than you are restricted on what you can test. For example, while I have
rules to flag mixmin posters using the MID header, I mostly rely on a
rule testing the PATH header to see if the article originated at a
mixmin server. PATH is a non-overview header. Even in my client, I
won't get the non-overview headers unless I configure the client to
retrieve the entire article, not just the overview headers. Retrieving
the entire article takes time but then I only visit text-only newsgroups
so the articles are small (but a huge count of articles will take a long
time to download on first subscribing to a newsgroup). Even if you
retrieve all of an article, whether you can test on non-overview headers
depends on what the client allows you to specify in their rules. While
I can do a lot in my choice of NNTP client, others with less capable
clients who want that level of filtering will have to employ their own
local NNTP server (eg., Hamster) to leech from their NNTP provider.

Filtering on MID likely gets you only *ONE* subthread to ignore, and you
would be retroactively editing your rule(s) to flag MIDs in new posts by
the unwanted poster. When the poster submits again, the MID will be
different. Filtering on the From header presumes the poster uses a
fixed nym (comment and e-mail fields). The more headers you can employ
in a rule then the more focused is your rule and less likely to incur
false positives on other posters you do want to see. You might be stuck
with only overview headers available in your rules. Some clients will
let you test on non-overview headers, too, provided you configure the
client to retrieve all of an article. There is the XPAT command to have
the client request the server to search for matching articles based on
any header but I've yet to find an NNTP provider that has this turned
on. It would waste a monsterous portion of their resources to let users
have their server performing searches, plus not many clients support
XPAT searches.

The starting thread remains listed as the first one in the References
headers but after that the leading MIDs will get removed to make room
for newer trailing MIDs (i.e., FIFO on MID removal except for the very
first MID). So the MID on which your rule checks could disappear from
the References header.

Is that just generally what happens, or is it part of some RFC?

Could be specified by an RFC but I'd have to dig into it. Could be it
is a de facto standard (as are signature blocks delimited by a line of
"-- \n" which is a de facto standard, not per RFC).

Servers don't need the References header. It is supplied only to allow
clients to thread the posts into hiearchical conversations. In fact,
the server doesn't add this header. The client(s) do. They compile the
References header on send to become part of the submitted message. The
next client that retrieves that article will append the MID for their
submitted article as a reply. If one client corrupts or deletes the
References header upon submit then it's lost to everyone else
thereafter. References is a client-generated header. A per RFC 5322,
section 3.6.4, mentioned below:

The "In-Reply-To:" and "References:" fields are used when creating a
reply to a message. They hold the message identifier of the original
message and the message identifiers of other messages (for example,
in the case of a reply to a message that was itself a reply).

It is also used in e-mail messages. Clients use the References header
to organize the posts into a tree or hierarchical structure to show
subthreading. I have run into users who e-mail clients (usually mobile
clients, like those on phones) do not add the References header. Every
time someone replies, it becomes a new thread. Very frustrating when
you are trying to have a conversation but the other person starts a
whole new thread. Some NNTP-to-HTTP gateways (web sites that leech from
Usenet to make their community look bigger or provide a webnews UI for
boobs to Usenet) don't keep or generated the References header which
****s over that thread (which is no longer a thread) back in Usenet.
Even Microsoft's own NNTPbridge proxy was ****ing up the References
header by inserting 20073bca-ecf4-4593-89b4-9fec1443bc4f as the MID in
the References header instead of .

As per RFC 5322 (https://tools.ietf.org/html/rfc5322), section 3.6, page
21, the References header may appear 0 or 1 times; that is, it is
optional but if present can appear only once. Any time an RFC specifies
"SHOULD" or "RECOMMENDED" means it optional. Only if something is
"REQUIRED" must it be present. There are a ton of SHOULDs that I'd like
to see become REQUIREDs. It is the *client* that replies (and updates
the References header), not the server. Everything on the server is
flat: just a bunch of articles in a database. Servers don't care about
hierarchy of articles (which replies to which). The server provides the
articles, not how they might be organized. It is because clients add
and manage the References header for why it is an optional header per
RFC 5322. Servers don't need it, don't use it, just some client
generated data to keep in the article.

I used to think the absence of the References header in someone's reply
but they used "" in the Subject header and even may have quoted
parent post content in the body meant they accidentally sent a new
message to start a new thread instead of replying to an existing thread.
Nope, some clients **** up by not adding the References header. Some
gateways don't add the References header to the forum posts (because
web-based forums don't use References to thread a conversation and
that's because most web-based forums are flat instead of hierarchical).

The truncation (reduction) of MIDs in the References header is caused by
clients that cannot branch depths of a tree beyond some maximum level.
Although the References header, as with most others, can have
continuation lines (following lines are preceding by one, or more, space
characters), it is still treated as one long string. Every program will
have a maximum length to a string. To keep that last portion of
threading intact, the string must be reduced in length to allow adding
the new MID for the parent post in a reply.

The maximum physical length of a header line is 998 octets (it's based
on really old hardware); see https://tools.ietf.org/html/rfc5536,
section 2.2, page 9. Continuation lines were created to exceed that
length limit; however, each physical line is still restricted to 998
octets maximum. That continuation lines can be used to bypass the
physical line length maximum does not obviate that programs will
encounter maximums in processing strings.

Some posters deliberately employ excessively long MID values. Their
intent is to more quickly break the threading by making the References
header's value too long to handle. I've seen such malicious posters
that had MID values of several hundred characters long. The MID header
(and PATH header) cannot span multiple physical lines. Breakage must
occur at a parsing point between multiple values and there are none
within a MID value so, in theory, a MID value could be up to 986 octets
(998 octets minus the 12 for "Message-ID: ").

In message , VanguardLH
writes:
J. P. Gilliver (John) wrote:

In message , VanguardLH
writes:
J. P. Gilliver (John) wrote:

Yes, I can mark a thread as "uninteresting", which I admit I'd
forgotten in this context. But I'd still have to see one followup
post to the person I'd killfiled to make/mark that thread
uninteresting.

That's why I said you'll have to investigate the settings within
Turnpike to see if it can apply the flag to all child posts of a parent
post flagged as "uninteresting". If the client cannot do that, there's
nothing you can do to emulate the effect.

It does that (when I mark a post/thread as uninteresting, I see no more
posts in that thread). But I still have to see the first one to mark it
as uninteresting: this is the first followup, as I don't see the
original post as that's by the person I've killfiled.

Does "killfile" mean you deleted the parent post or you flagged it (and
hidden it)? Deleting means the client may no longer keep track of that
parent post. Presumably you are using a rule or filter to set an
"uninteresting" flag on an unwanted post; else, you'll have to do it
manually on every parent post you don't want to see.

I used "killfile" as it seems a common term for: I've set a rule to not
see posts by a certain poster. I _assume_ that uses the From: header,
but have no idea in practice; it works, so I don't worry.

When you say "followup", are you talking about replies or the use of the
FollowUp-To header?

I'm talking about posts which Turnpike recognises as being in the same
thread. I _assume_ it does that by using the References: header. (Within
Turnpike, if _I_ hit "Reply", it sends a private email to the poster of
the post I have open, usually asking me to confirm that that's what I
want to do rather than post a followup to the 'group; if I hit Followup,
it posts a followup. But other clients may use the terms differently.)

In another 'group,
I've been able to set up a rule based on the References header that
stops me seeing any posts by a particular poster _and_ any followups to
that person's posts,
why (-:! There probably isn't _any_ way to do that in this case, other
than seeing the first followup and marking the thread uninteresting.

The MID header is going to change every time a poster submits an
article. All you can filter out is ONE thread by MID. The next time
the poster submits, their MID will be something different. The only
filtering on MID would eliminate all posts by someone is if that someone
always uses a right-token that remains the same and is never used by
anyone else, like varstring@theirdomain where they registered
theredomain and no one else uses it. I have my NNTP client use a unique

That's how it works in the case of the other poster on the other
newsgroup. The one here seems to have nothing consistent in his/her
MIDs.

right-token in my MID header but it isn't registered and anyone could
use it, not just me. Someone could attempt to forge my identity and I
couldn't stop them (unless they used the same NNTP provider and I
complained to get their account killed - which obviously works only at
registered NNTP provides).

If they are using a common right-token or they aren't assigning one at
all and letting the NNTP server assign one then you cannot use MID to
filter out all posts by one poster, only one of their posts (and replies
to it by checking the References header). You would need to define a
blacklist rule that lists every MID used in the past and then for the
new articles that show up, something like:

^References: \S*(mid1|mid2|...|midN)

But that list would have to get manually updated by you after you see
their next new post. Doesn't look like Turnpike is working for you
regarding its "uninteresting" flag. If it did, you should be able to
define a rule to identify the *poster* to then set the uninteresting
flag (and recurse that flag onto any child posts). If you don't want to

The "uninteresting" flag applies to threads, not posters. I can't mark
an Author as uninteresting, only Kill.
[]
To better filter on unwanted posts (content) or posters, you need to
include the non-overview headers in your filters. However, most NNTP
clients will only retrieve the overview headers. Even if they let you

I don't even know what the difference is. But _please_ don't tell me!
This was just a minor wonder: you've already spent _far_ too much time
on it for me!
[another ~31 lines!]
The starting thread remains listed as the first one in the References
headers but after that the leading MIDs will get removed to make room
for newer trailing MIDs (i.e., FIFO on MID removal except for the very
first MID). So the MID on which your rule checks could disappear from
the References header.

Is that just generally what happens, or is it part of some RFC?

Could be specified by an RFC but I'd have to dig into it. Could be it
is a de facto standard (as are signature blocks delimited by a line of
"-- \n" which is a de facto standard, not per RFC).

That's interesting: I thought, from the number of both people and
clients that ignore it, it must be an RFC. (People and programmers
generally ignore RFCs.)
[]
It is also used in e-mail messages. Clients use the References header
to organize the posts into a tree or hierarchical structure to show
subthreading. I have run into users who e-mail clients (usually mobile
clients, like those on phones) do not add the References header. Every
time someone replies, it becomes a new thread. Very frustrating when
you are trying to have a conversation but the other person starts a
whole new thread. Some NNTP-to-HTTP gateways (web sites that leech from

I don't think Turnpike does threads in email, though if there's an RFC
that says it should do something with Reference: headers, it probably
does.

[another 54 lines]
I submit! (Bangs arm on canvas.)
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Of course some of it [television] is bad. But some of everything is bad -
books, music, family ... - Melvyn Bragg, RT 2017/7/1-7