Re: Killfiling by miscellaneous Header Info
- From: VanguardLH <V@xxxxxxxxx>
- Date: Mon, 30 Mar 2009 20:49:43 -0500
Thistle wrote:
Hi all.
If anyone can help me, I would be much obliged.
My newsgroup has a fairly serious and unpleasant troll infestation.
These disharmonious feminine hygiene products shift nyms with such
frequency it is nigh impossible to killfile the reprehensible male
private parts.
However, they do have one thing in common. The message ID's always end
in @poisonous.dizum.com; and the mail-to-news-contact is always
abuse@xxxxxxxxxx
In addition, the posting-account=5IFQQgoAAAAbGlDKo88Rm38xxGWQT5w_
A lot of us use the thunderbird reader, some use xnews, some use
outlook, and of course the poor google users are screwed any road.
Are there any specific readers that allow a user to set killfiles using
custom header info?
There will truly be much rejoicing in my corner of usenet if you can
point me in any direction which will send these sorry spankards to the
plonk pit they so richly deserve.
TIA
Thistle
Dizum is a remailer to hide the original poster. Currently I only
red-color these posts because quite often these hiding posters hide
because of the content they post. I use the following filters in my
newsreader:
!setcolor(red;white),markread Header
{^Path:.*(\!mail2news$|\.mixmin\.net(\!not-for-mail|$))}
If it gets bad enough, I'll add the ignore and markread flags and those
posts will disappear from my Hide Ignored Posts view (which is the
default). The above is a regular expression. I believe Thunderbird,
your newsreader, lets you test on any header in version 3 (but not in
version 2 of Tbird). However, I don't recall if Tbird supports regex.
I test on the Path header because it is managed by the NNTP servers, not
the posters (with exceptions, of course). The Message-ID may be managed
by the poster. NNTP servers are required to add the Message-ID header
*if* it is missing. If it is present, like the user's NNTP client added
it, it is /optional/ whether the NNTP server overrides by removing it
and inserting their own or leaves it alone. Seems like most NNTP
servers won't overwrite that header if already present, so the user gets
to put whatever they want in there. Only if they don't have their
newsreader add it will the NNTP server add it. So I don't rely on that
header unless it is obvious the NNTP server is adding it. Forte Agent
users get 4ax.com, by default unless they change it, in the domain
portion of the Message-ID and that's worthless for filtering (unless you
dislike all Forte Agent users).
In the above regex (I escape the "!" characters although I'm not sure it
is really needed), I'm looking for "!mail2news" at the end of the Path.
Many remailers add this. Mixmin is different that they keep the
"!not-for-mail" node at the end of the Path (so it looks like a normal
post) but the next node identifies them; however, I have seen their host
at the end of the Path (and without the "!mail2news" node after it).
Dizum adds the "!mail2news" at the end so testing on that also captures
posts through Dizum. I look for these at the end of the Path although
it might work to look for them anywhere in that header. So you might be
able to check for "!mail2news" and "mixmin.net" anywhere in the Path
header providing you are using a version of Tbird that lets you specify
the header on which you want to test (I think that showed up in v3)
because you want to test for those strings in the Path header. E-mail
filters in Tbird suck just as bad as in OE (actually worse than OE) and
did not improve in v3 but they might've improved their newsgroup filters
in v3 to allow testing on any header. I doubt they have yet added regex
support but you can probably get away with just testing for substrings
in the Path header's value.
Use the Message-ID header when it is obvious that the NNTP server is the
one inserting that header. That is why it is handy for those who want
to filter out the Google Groups users because they are using the webnews
agent providing by Google (and not their own newsreader). Users can
employ newsreaders that generate their own Message-ID header which the
NNTP server will not overwrite. The Message-ID header is included in
the overview headers. Those are the ones retrieved when your newsreader
only gets a list of new posts from the server. Normally the newsreader
only retrieves the overview headers so it can populate the message list
to show you the new posts. A filter that tests on the Message-ID can
test on the articles when just their overview headers have been
retrieved.
My solution has the requirement that you download the bodies of the
posts so the non-overview headers can be interrogated. The Path header
is not an overview header. So in my newsreader, I configure it to
download the bodies of the posts, not just their [overview] headers.
That takes more time but gives me a hell of lot more headers on which I
can test. You don't want to be testing on non-overview headers which
require download the bodies of those new posts if you are visiting
binary groups. The size of the attachments to those binary posts would
take far longer to download then you have patience to wait (but then you
should be using a newsreader geared to collecting binaries than for
posting messages which means it would be highly unlikely that you read
any portion of those binary posts that have readable text in them).
Another problem is that the newsreader would have to make a 2nd pass
through its filters: once when it retrieved the overview headers for new
posts and again after retrieving the bodies for those new posts. This
takes time. It also can have side effects if you don't watch how you
define your filters. One pass would be possible if, when the option to
download the bodies (and not just headers) was enabled, the newsreader
didn't apply any rules until after the bodies got downloaded.
I don't know if remailers, like Dizum, overwrite the Message-ID header
that might already be inserted by the poster or if they let the poster's
header remain in place. Considering how they are used (but without
knowing the intent or personalities of the owners that operate those
services), I wouldn't trust the Message-ID header to be testable through
remailers. You would be ignoring or deleting posts from anyone that had
dizum.com in their Message-ID. If Dizum overwrites that header with
their own, the result is you filter out everyone using that remailer.
Once you decide to filter on Message-ID (or Path if your newsreader is
capable), you might consider just "where" you want the filter applied.
For example, I filter out all Google Groups posters but only in the
non-Microsoft newsgroups. I haven't use Tbird for awhile (your
newsreader) but I recall that you could specify if a filter was global
(all groups) or applied only to a particular newsgroup
(microsoft.public.outlook or to a newsgroup hierarchy (like
microsoft.public.*). My filter (on Path) applies to all newsgroups
except microsoft.* (to include their public and private groups).
[*]
# Dim posts through Google Groups.
!setcolor(gray;white) Message-ID {<.+\.googlegroups\.com>}
....<more filters>...
## Rules that apply to all groups except for those specified.
[* -{^microsoft\..*}]
# Ignore posts through Google Groups.
!setcolor(silver;white),ignore,markread Message-ID
{<.+\.googlegroups\.com>}
First I dim all Google Groups posts (so they are still identified when I
visit the microsoft.* groups). Then I delete them except if they are in
a microsoft.* group. I have far less problems (mostly spam) in
microsoft groups that originate from Google Groups' webnews agent. I
recall in Tbird that you could specify how far to travel down a
hierarchy to specify to which groups a filter applied but I don't recall
if it had the ability to exclude specific groups or hierachies of them.
Soon after I gave up on OE as a newsreader, I trialed and very quickly
gave up on Tbird as a newsreader; however, v3 of Tbird wasn't out yet.
It still won't do everything that I want but might be usable to you.
Don't bother testing on the Path header unless Tbird v3 has the ability
to [re]exercise its filters after the body of new posts have been
downloaded; otherwise, the filter won't ever trigger (since Path isn't
an overview header).
Just remember to review your filters occasionally. Trolls come and go,
and you may no longer want to filter out others using the same
Message-ID (or Path) string that the troll used. Since they can specify
their own Message-ID header (and if Dizum leaves them as-is) then not
only will they nymshift but they'll also configure their newsreader to
insert some other string and rotate it as often as they do their nym
(and even create multiple identities in their newsreader to make it easy
and some newsreaders let users change headers on-the-fly so they don't
even have to bother configuring their newsreader).
Also, rather than deleting the troll's posts, you might want to instead
just ignore it (mark with a flag) and use a Hide Ignored Posts view.
Some newsreaders can ignore on subthreads. Many can't. I don't know
about Tbird. If you ignore the entire thread, you miss out on the
conversation between the non-trolls. If you ignore on a subthread, you
only ignore the troll and any replies to the troll. Using a view can
then hide all those ignored posts in the subthread. If you delete the
troll's posts, anyone replying to the troll will start a new subthread
(as you see it in your newsreader). Do you really want to see any
replies to the troll that you are trying to avoid? Whether you can hide
the replies depends on your newsreader. Someone familiar with Tbird
could answer if it can apply the ignore flag on a subthread or only on
the entire thread. If it can ignore on a subthread, will it keep the
chain intact when a post is deleted in that ignored chain of posts in
the subthread? Might want to ask in a mozilla.* newsgroup (they have
their own NNTP server at news.mozilla.org).
.
- References:
- Killfiling by miscellaneous Header Info
- From: Thistle
- Killfiling by miscellaneous Header Info
- Prev by Date: Re: [MP Gravity] feature request (was: Minor gripes)
- Next by Date: Re: Killfiling by miscellaneous Header Info
- Previous by thread: Re: Killfiling by miscellaneous Header Info
- Next by thread: Re: Killfiling by miscellaneous Header Info
- Index(es):
Relevant Pages
|
