Re: Filter

[Heiko Rost]

Beate Goebel schrieb:

> Kann man auf path filtern?

Ja, indem Du ein ? an den Beginn der Scorezeile setzt und damit dem
Hamster sagst, daß er die Regel erst *nach* dem Laden des Artikels
auswerten soll. Das funktioniert dann mit jedem Header-Feld, unabhängig
davon, ob es im Overview enthalten ist.

> freedyn.de wirft zZ jede Menge Uraltposts neu in die Gruppen.
>
> Siehe, wenn möglich:
>
> Newsgroups: eternal-september.support
> Message-ID: <srctgp$788$1...@apd.eternal-september.org>
>
> Random very old posts appearing in various groups from yesterday, all
> from the same source: "news.freedyn.de".
>
> Path: ... reader02.eternal-september.org!news.freedyn.de!not-for-mail

?=-9999 ~path: {!news\.freedyn\.de!not-for-mail$}

Allerdings ungetestet, da mich entweder mein Age-Filter oder die 2000
Tage Haltezeit der History vor der Zombie-Apokalypse geschützt haben:

=-7000 age: %>365 #zu alte Postings killen

Gruß Heiko
--
Faule Engel taugen weniger als fleißige Teufel.
Emil Gött

[Thomas Hochstein]

Beate Goebel schrieb:

> freedyn.de wirft zZ jede Menge Uraltposts neu in die Gruppen.

Das ist eigentlich kein Problem, weil die wegen des zu alten Datums
rejected werden. Offenbar gibt es bei eternal-september aber eine
Fehlkonfiguration; Ray nimmt die Postings munter an und feedet sie auch
weiter. Mein Server hat bisher über 1.000 abgewiesen.

-thh

[Ruediger Lahl]

*Beate Goebel* schrieb:

> Heiko Rost schrieb am 09 Jan 2022

>> Beate Goebel schrieb:
>>
>>> Kann man auf path filtern?
>

>> ?=-9999 ~path: {!news\.freedyn\.de!not-for-mail$}
>

> Danke. Ich probiers mal. Obwohl der aufgewärmte Thread in de..haushalt
> sich produktiv weiterentwickelt. ;-)

>
>> Allerdings ungetestet, da mich entweder mein Age-Filter oder die
>> 2000 Tage Haltezeit der History vor der Zombie-Apokalypse
>> geschützt haben:
>>
>> =-7000 age: %>365 #zu alte Postings killen
>

> Ich habe das Problem mit aioe.
>
> Weder
>
> -999 Message-ID: {aioe\.org}
>
> noch
>
> -999 Message-ID: "gioia.aioe.org" "aioe.org"
> -5000 from: {.*@.*aioe.org}
>
> verschonen mich vollständig vor diese Usern.

-9999 sollte doch helfen, oder?
--
bis denne

[Thomas Hochstein]

Beate Goebel schrieb:

> Danke. Ich probiers mal.

Der Betreiber von freedyn.de hat mir mitgeteilt, dass seit heute kurz
vor 14 Uhr keine neuen Dupes mehr erscheinen dürften.

[Heiko Rost]

Beate Goebel schrieb:

> Ich habe das Problem mit aioe.
>
> Weder
>
> -999 Message-ID: {aioe\.org}
>
> noch
>
> -999 Message-ID: "gioia.aioe.org" "aioe.org"
> -5000 from: {.*@.*aioe.org}
>
> verschonen mich vollständig vor diese Usern.

Was auch nicht verwundert, da Message-Id: und From: ggf. vom Newsreader
gesetzt werden und dann nicht sicher von Deinen Regeln gefunden werden.
Wenn es darum geht, alle über aioe.org eingeliefen Postings zu finden,
dürfte

?=-9999 Injection-Info: "gioia.aioe.org;"

passend sein.

Gruß Heiko
--
Jeder Zwang ist Gift für die Seele.
Ludwig Börne

[Thomas Hochstein]

Beate Goebel schrieb:

> Von "Injection-Info:" hab ich noch nie was gehört.

Das ist der "standardisierte" Nachfolger von "X-Trace" (und
"NNTP-Posting-Host" und "NNTP-Posting-Date").

Man - namentlich Russ Allbery, denke ich - hat 2009 endlich aktuelle und
einigermaßen zukunftssichere RfCs für

a) das Artikelformat - RFC 5536 "Netnews Article Format";
ersetzt RFC 1036 von 1987, der RFC 850 von 1983 ersetzte

b) die generellen Abläufe und Anforderungen an Clients, Server und
andere Beteiligte - RFC 5537 "Netnews Architecture and Protocols";
ersetzt ebenfalls RFC 1036

geschaffen. 2018 hat man (Michael Bäuerle) sogar Cancel-Locks und -Keys
in einen RFC gegossen (RFC 8315).

Kurz vor dem Usenet-Artikelformat, das ja weitgehend auf dem
E-Mail-Format basiert, hat man auch das aktualisiert (200) in Form von
RFC 5322 "Internet Message Format", der RFC 2822 von 2001 ersetzt (der
wiederum RFC 822 von 1982 ersetzt hatte).

Das ist alles noch einigermaßen neu - nicht weil jüngeren Datums (2009
sind jetzt mehr als 12 Jahre her), aber weil es zu einer Zeit kam, als
das Usenet weltweit im Niedergang begriffen war und es selbst in de.*
kaum mehr RFC-Diskussionen gab. :)

Der INN setzt aber die neuen Standards Stück für Stück
(rückwärtskompatibel) um.

-thh

[Alfred Peters]

Es schrieb einmal Thomas Hochstein:

Dupes sind es streng genommen nicht. Sie haben noch die alte Message-ID.

Soweit ich das das sehe, sind das Artikel, die ursprünglich mal
gecancelt oder superseded wurden. Zumindest, was es hier in meinen
Hamster schafft. ;-)

Alfred
--
22024.2

[Alfred Peters]

Es schrieb einmal Beate Goebel:
> Thomas Hochstein schrieb am 09 Jan 2022

>
>> Beate Goebel schrieb:
>>
>>> Von "Injection-Info:" hab ich noch nie was gehört.
>>
>> Das ist der "standardisierte" Nachfolger von "X-Trace" (und
>> "NNTP-Posting-Host" und "NNTP-Posting-Date").

>> Der INN setzt aber die neuen Standards Stück für Stück
>> (rückwärtskompatibel) um.
>

> Ich hoffe, der Hamster weiß auch wovon die Rede ist.
> Wenn ich mich jetzt so umschaue, hat sich das auch noch nicht
> wirklich allgemein durchgesetzt:
> Header MID: <j40ru4...@mid.individual.net>

Ich fürchte, du bringst da jetzt etwas durcheinander. Was haben die
Header mit dem aktuellen Problem zu tun? Das Filtern im Hamster
funktioniert bei alt wie neu gleich.

Alfred
--
22024.7

[Thomas Hochstein]

Beate Goebel schrieb:

> Wenn ich mich jetzt so umschaue, hat sich das auch noch nicht
> wirklich allgemein durchgesetzt:

news.indidvual.de düfte eine ... sehr individuell modifizierte Variante
an Newsserversoftware laufen haben oder (bzw. deshalb) keine aktuelle
INN-Version betreiben.

[Heiko Rost]

Beate Goebel schrieb:

> Nun, in Deinem Haeder finde ich kein "Injection-Info" sondern "X-
> Trace".

Das sind Headereinträge, die der Newsserver erstellt. Der Hamster hat
mit denen nichts zu tun. Obwohl er aus Deiner Sicht bzw. der Deines
Newsreaders wie ein Server arbeitet, ist er für den Server beim Provider
auch nur ein Newsreader. Deshalb kann er beim Versenden letztendlich
nicht mehr machen als ein beliebiger Newsreader.

> Also sollte der Hamsterfilter mit allen möglichen Headerzeilen
> klar kommen.

Der Hamster kann in zwei Stufen filtern.

Zuerst holt er sich beim Newsserver den Overview, der nur einige
Headerfelder enthält. Das sind Subject:, From:, Date:, Message-ID:,
References:, Bytes:, Lines: und Xref; (letzteres ist IIRC nur optional,
wird aber praktisch immer gesendet). Deshalb kann der Hamster vor dem
Laden des kompletten Postings auch nur auf diese Felder filtern. Wobei
ich allerdings nicht weiß, ob die in RFC 3977 definierten Einträge
:bytes und :lines bereits vor irgendwelchen Servern benutzt werden, für
die müßte wahrscheinlich der Hamster aktualisiert werden.

Nach dem Laden kann der Hamster dann auf jedes beliebige Feld filtern,
weil er den kompletten Header hat und nicht mehr auf den Overview
angewiesen ist. Ob das irgendwelche neu in den Standard aufgenommen
Header sind oder frei erfundene (die mit X- beginnenden sind zur freien
Verfügung vorgesehen und nicht standardisiert), spielt dabei keine
Rolle.

Und damit der Hamster unterscheiden kann, ob vor oder nach dem Laden des
Postings gefiltert wird, werden die Regeln für den letzten Fall mit
einem ? am Beginn gekennzeichnet.

Gruß Heiko
--
Wie seltsam ist doch unsere Seele konstruiert
und an wie dünnen Fäden hängt Glück oder Verderben
Mary Shelly

[Alfred Peters]

Es schrieb einmal Heiko Rost:

> Beate Goebel schrieb:
>
>> Nun, in Deinem Haeder finde ich kein "Injection-Info" sondern "X-
>> Trace".
>
> Das sind Headereinträge, die der Newsserver erstellt. Der Hamster hat
> mit denen nichts zu tun. Obwohl er aus Deiner Sicht bzw. der Deines
> Newsreaders wie ein Server arbeitet, ist er für den Server beim Provider
> auch nur ein Newsreader. Deshalb kann er beim Versenden letztendlich
> nicht mehr machen als ein beliebiger Newsreader.
>
>> Also sollte der Hamsterfilter mit allen möglichen Headerzeilen
>> klar kommen.
>
> Der Hamster kann in zwei Stufen filtern.
>
> Zuerst holt er sich beim Newsserver den Overview, der nur einige
> Headerfelder enthält. Das sind Subject:, From:, Date:, Message-ID:,
> References:, Bytes:, Lines: und Xref; (letzteres ist IIRC nur optional,
> wird aber praktisch immer gesendet).

Ja. Im Prinzip darf der Server beliebige zusätzliche Header in den XOVER
aufnehmen. Dem Hamster kann man das über "local.nntp.XOVERExtraFields"
beibringen. Nur wird wohl kaum ein Client davon Gebrauch machen. Außer
vielleicht einem 2. Hamster. :-D

> Deshalb kann der Hamster vor dem
> Laden des kompletten Postings auch nur auf diese Felder filtern. Wobei
> ich allerdings nicht weiß, ob die in RFC 3977 definierten Einträge
> :bytes und :lines bereits vor irgendwelchen Servern benutzt werden, für

Durchaus. Nur gehören die zum OVER und nicht zum XOVER.
Der Unterschied ist: beim XOVER darf der Server die Informationen aus
einem Header (Lines: etc.) benutzen - die dann auch falsch sein könnten.
Für den OVER muss er im Zweifel jedes mal die tatsächliche Zahl bestimmen.

> die müßte wahrscheinlich der Hamster aktualisiert werden.

Ja, OVER kennt der Hamster nicht.

Alfred
--
22026.7

[Heiko Rost]

Alfred Peters schrieb:

>> Deshalb kann der Hamster vor dem
>> Laden des kompletten Postings auch nur auf diese Felder filtern. Wobei
>> ich allerdings nicht weiß, ob die in RFC 3977 definierten Einträge
>> :bytes und :lines bereits vor irgendwelchen Servern benutzt werden, für
>
> Durchaus. Nur gehören die zum OVER und nicht zum XOVER.

Worauf ich hinaus wollte (siehe auch letzten Abschnitt des Postings,
folgender Text ist die Erklärung zu meinem Vorposting): In
<https://datatracker.ietf.org/doc/html/rfc2980#section-2.8> steht zum
Thema XOVER:

| The
| sequence of fields must be in this order: subject, author, date,
| message-id, references, byte count, and line count.

Hier steht, daß die Reihenfolge fest vorgegeben ist.

| The LIST OVERVIEW.FMT command should be implemented if XOVER is
| implemented. A client can use LIST OVERVIEW.FMT to determine what
| optional fields and in which order all fields will be supplied by
| the XOVER command. See Section 2.1.7 for more details about the LIST
| OVERVIEW.FMT command.

Nach diesem Abschnitt kann der Client das Ergebnis von "LIST
OVERVIW.FMT" benutzen, um die Reihenfolge *aller* Felder zu ermitteln.
Zumindest meiner Interpretation nach, andernfalls müßte es "all optional
fields" heißen. Und falls der Hamster das so macht und dann an Stelle
von "Lines:" ein ":lines" bekommt, könnte es zu Problemen führen.

[etwas später]

Ok, da habe ich voreilig geschlußfolgert. Der Hamster speichert zwar die
vom Server mit LIST OVERVIEW.FMT gemeldeten Felder in der Datei
overview.txt ab, diese scheint aber rein informativen Zwecken für den
User zu dienen und wird vom Hamster selbst nicht ausgewertet.

Gruß Heiko
--
Besser ein freier Teufel als ein gebundener Engel.
Peter Hille

[Alfred Peters]

Es schrieb einmal Heiko Rost:

> Alfred Peters schrieb:
>
>>> Deshalb kann der Hamster vor dem
>>> Laden des kompletten Postings auch nur auf diese Felder filtern. Wobei
>>> ich allerdings nicht weiß, ob die in RFC 3977 definierten Einträge
>>> :bytes und :lines bereits vor irgendwelchen Servern benutzt werden, für
>>
>> Durchaus. Nur gehören die zum OVER und nicht zum XOVER.
>
> Worauf ich hinaus wollte (siehe auch letzten Abschnitt des Postings,
> folgender Text ist die Erklärung zu meinem Vorposting): In
> <https://datatracker.ietf.org/doc/html/rfc2980#section-2.8> steht zum
> Thema XOVER:
>
> | The
> | sequence of fields must be in this order: subject, author, date,
> | message-id, references, byte count, and line count.
>
> Hier steht, daß die Reihenfolge fest vorgegeben ist.
>
> | The LIST OVERVIEW.FMT command should be implemented if XOVER is
> | implemented. A client can use LIST OVERVIEW.FMT to determine what
> | optional fields and in which order all fields will be supplied by
> | the XOVER command. See Section 2.1.7 for more details about the LIST
> | OVERVIEW.FMT command.
>
> Nach diesem Abschnitt kann der Client das Ergebnis von "LIST
> OVERVIW.FMT" benutzen, um die Reihenfolge *aller* Felder zu ermitteln.
> Zumindest meiner Interpretation nach, andernfalls müßte es "all optional
> fields" heißen. Und falls der Hamster das so macht und dann an Stelle
> von "Lines:" ein ":lines" bekommt, könnte es zu Problemen führen.

Wie ich schon schrieb: ":lines" gibt es nicht im XOVER - Nur im OVER
nach RFC 3977.

> [etwas später]
>
> Ok, da habe ich voreilig geschlußfolgert. Der Hamster speichert zwar die
> vom Server mit LIST OVERVIEW.FMT gemeldeten Felder in der Datei
> overview.txt ab, diese scheint aber rein informativen Zwecken für den
> User zu dienen und wird vom Hamster selbst nicht ausgewertet.

Ja - da war bei mir wohl der Wunsch Vater des Gedankens. :-(

Alfred
--
22027.4

[Henning Sponbiel]

On Sun, 9 Jan 2022 18:46:28 +0100, Heiko Rost wrote:

>
>Was auch nicht verwundert, da Message-Id: und From: ggf. vom Newsreader
>gesetzt werden und dann nicht sicher von Deinen Regeln gefunden werden.
>Wenn es darum geht, alle über aioe.org eingeliefen Postings zu finden,
>dürfte
>
>?=-9999 Injection-Info: "gioia.aioe.org;"

?=-500 NNTP-Posting-Host {aioe\.org>$}

geht auch noch.


Henning

[Heiko Rost]

Beate Goebel schrieb:

> Also, das hier kam durch:
> Message-ID: <sspnh1$1lil$1...@gioia.aioe.org>
>
> Kann allerdings sein, weil es eine direkte Antwort auf mein Posting
> war.

Zum Hamster Classic gehört das Kommandozeilenprogramm ham, das zeigt Dir
mit

ham scoretest "<sspnh1$1lil$1...@gioia.aioe.org>"

an, welche der aktuell im Scorefile stehenden Regeln (es lassen sich
also auch Änderungen prüfen) für das Posting zutreffen. Etwas bequemer
ist HamScore von <https://heiros.lima-city.de/>, damit kannst Du eine
komplette Gruppe testen.

Falls ham oder HamScore nicht funktionieren, ist bei Deinem Hamster
wahrscheinlich der OLE-Server nicht gestartet. Dieser läßt sich in
"Einstellungen" - "Automatische Abläufe" - "Allgemeines" aktivieren.
Anschließend muß der Hamster einmal als Administrator gestartet werden,
da andernfalls der dafür notwendige Eintrag in der Registry nicht
möglich ist.

Gruß Heiko
--
Wer unter Menschen nur einen Engel sucht, der findet kaum Menschen.
Wer aber unter Menschen nur Menschen sucht, der findet gewiß seinen Engel.
Moritz Gottlieb Saphir

[Heiko Rost]

Beate Goebel schrieb:

> =+9998 References "@ID-12795.user.dfncis.de"
>
> Alles klar, ne? Ich habe den Zähler mal um 1 runtergesetzt.

Wegen dem "=" am Anfang wird, sobald diese Filterzeile auf das
entsprechende Posting zutrifft, das Scorefile nicht weiter abgearbeitet
und der Wert hinter dem "=" als endgültiger Wert genommen. Wenn die
Verringerung auf 9998 die einzige Änderung ist, hat das nicht die
gewünschte Wirkung.

Bei Deinem

| ?=-500 NNTP-Posting-Host {aioe\.org>$}

ist es letztendlich das selbe: Steht diese Zeile *vor* Deinem
References-Filter, bekommt das Posting eine -500. Wenn diese Zeile
*nach* dem References-Filter steht, wird sie gar nicht erst ausgewertet,
weil der Hamster nicht bis zu dieser Zeile kommt.

Gruß Heiko
--
Wo ein Wille ist, ist auch ein Weg.
Sprichwort

[Heiko Rost]

Beate Goebel schrieb:

> Das heißt
>
> # Load articles referencing one of "my" articles:
> [*]
> =+9998 References "@ID-12795.user.dfncis.de"
>
> muss eigentlich an letzter Position im Killfile stehen?

Das kommt drauf an. Du mußt erst genau überlegen, was Dein Scorefile
machen soll, bevor Du irgendwelche Regeln plazierst. In diesem Fall ist
die Frage, ob Du absolut alles von aioe ignorieren willst oder ob Du
Postings von diesem Server ausnahmsweise doch lesen willst, wenn es
Antworten auf Deine eigenen sind.

Wobei man die Regeln in dem Zusammenhang in zwei Gruppen einteilen kann:

(1)

Regeln, die ein "=" vor der Zahl haben, legen endgültige Werte fest.
Sobald die erste Regel dieser Art zutrifft, ist das der Score für dieses
Posting.

Wenn Du also zuerst die References-Regel hast, wird das Posting auf
jeden Fall geladen, selbst wenn später noch andere kommen, die das Laden
verhindern könnten, wenn es keine Antwort auf Deine Postings wäre.

Wenn Du hingegen sagst, daß Du aioe-Postings auf keinen Fall lesen
willst, muß die aioe-Kill-Regel weiter oben stehen.

(2)

Die andere Gruppe sind Regeln, bei denen die Werte der zutreffenden
Zeilen aus dem Scorefile addiert bzw. subrahiert werden. Das Ergebnis
dieser Rechnung wird benutzt, wenn keine der Regeln unter (1) zutreffen.

Auf nur zwei vereinfacht, könntest Du beispielsweise

+9000 References "@ID-12795.user.dfncis.de"
?-500 NNTP-Posting-Host {aioe\.org>$}

schreiben. Dann haben die Postings am Ende einen Score von

+9000: Antworten auf Deine Postings, die nicht von aioe kommen
+8500: Antworten auf Deine Postings, die von aioe kommen
-500: Postings von aioe, die keine Antworten auf Deine Postings sind
+0: alle anderen, weil keine der beiden Regeln zutrifft

Jetzt werden nur die mit einem positiven Wert (die 0 sehe ich der
Einfachheit halber auch als positiv an) geladen und der eine negative
Fall nicht.

Bei zwei Regeln ist das natürlich nur bedingt sinnvoll, sondern erst bei
Auswertung von einer größeren Zahl positiver und negativer Werte, die in
ihrere Summe festlegen, ob das Posting positiv oder negativ bewertet
wird.

(3) <bg>

Eigentlich gibt es noch eine Ausnahme vom oben Geschriebenen, wenn
Regeln auf den Overview und nach dem Laden (also die mit "?" vor der
Zahl) gemischt sind, das macht die Erklärung aber wahrscheinlich etwas
zu verwirrend und ist bei der konkreten Frage erst einmal unwichtig.

[Thomas Hochstein]

Beate Goebel schrieb:

> Das heißt
>
> # Load articles referencing one of "my" articles:
> [*]
> =+9998 References "@ID-12795.user.dfncis.de"
>
> muss eigentlich an letzter Position im Killfile stehen?

Vermutlich willst Du eher das "=" weglassen.

Zweck eines *Score*-Files (im Ggs. zu Watch-/Kill-Filtern) ist es ja
üblicherweise, Postings positive und negative Werte zuzuweisen, die
addiert und subtrahiert werden und so gewählt sind, dass am Ende genau die
Postings sichtbar bleiben, die man sehen will, und die anderen nicht.

Das erreichst Du nicht, wenn Du einem Posting einen Wert zuweist und
danach die Auswertung abbrichst. Auf diese Weise kannst Du natürlich mit
einem Score-File stattdessen Watch- und Kill-Filter erstellen, musst dann
aber genau auf die Reihenfolge achten, in der sie ausgewertet werden, und
verlierst Flexibilität.

-thh

[Heiko Rost]

Beate Goebel schrieb:

> Also, sieht jetzt so aus:

>
> # Load articles referencing one of "my" articles:
> [*]

> +9998 References "@ID-12795.user.dfncis.de"
>
> an erster Position. Dann kommt viel dazwischen. Und vor den
> Dauerpostings kommt zuletzt
>
> # Anonyme Trolle
> [*]
> ?=-500 Injection-Info: "gioia.aioe.org;"

> ?=-500 NNTP-Posting-Host {aioe\.org>$}
>

> In der Hoffnung, dass sich die beiden addieren.
> Oder sollte da das "=" auch raus?

So wie es da steht, wird nichts addiert, sondern die aioe-Postings
bekommen immer -500, sobald eine der letzten beiden Zeilen zutrifft.
Falls ich Deine Antwort an Thomas richtig verstehe, ist es genau das,
was Du willst. Und zusätzlich solltest Du die "Solche Postings will ich
nie und nimmer und auf keinen Fall lesen"-Killfilter mit einem "=" an
den Anfang stellen, damit nicht irgendeiner der vielen Zeilen dazwischen
möglicherweise wegen einem fort benutzten "=" den Killfilter umgehen.

> PS. Und wenn ich das verstanden habe, kann mir sicher jemand
> erklären, warum ich Arcor, seitdem es Vodaphone ist, nicht mehr in
> den Hamster bekomme. Glaube, das hat was mit SSL/TLS zu tun.

Den Newsserver news.arcor.de gibt es schon seit Ewigkeiten nicht mehr,
und pop3.arcor.de läßt sich bei mir problemlos mit TLS 1.2 abrufen,
Versand über Vodafone habe ich nicht konfiguriert. Die einzige Falle bei
der Umstelleung war IIRC, daß der Benutzername nicht mehr "foobar",
sondern "foo...@arcor.de" lauten muß. Falls es immer noch nicht geht,
solltest Du einen neuen Thread beginnen und ein Log des entsprechenden
Abruf-Thread mit allen Leveln *außer* debug posten.

Gruß Heiko
--
Keine Unterwerfung ist so vollkommen wie die, die den Anschein der Freiheit
wahrt. Damit lässt sich selbst der Wille gefangen nehmen.
Jean-Jacques Rousseau