[Individual] Verbesserung der Cancelverarbeitung
NetNews-Team Individual.DE
Überschreiben von Artikeln) entstammt noch den Kindertagen der
elektronischen Kommunikation und vertraut ohne besondere Absicherungen
auf das verantwortungsbewusste Verhalten aller Usenet-Nutzer. Leider
kann man davon in den heutigen Zeiten nicht mehr ausgehen.
In den letzten Monaten haben wir eine starke Zunahme von Fremdcancels
und Fremdsupersedes im Usenet beobachtet, sowohl in de.* als auch -
deutlich stärker - in den Big-8. Dies schließt auch recht ausgefeilte
Methoden zur Verschleierung mit ein, die den Nutzern kaum noch eine
Möglichkeit des Nachvollziehens einräumen. Deshalb haben wir uns dazu
entschlossen, Cancels und Supersedes künftig auf unseren Servern im
Grundsatz nicht mehr auszuführen, und haben stattdessen Methoden
implementiert, die nur noch Cancels und Supersedes aus
vertrauenswürdigen oder verifizierten Quellen verarbeiten.
Hierzu haben wir einerseits eine Whitelist von Absendern erstellt;
diese enthält Despammer ("professionelle" Spam-Canceller), damit deren
erwünschte Spamcancels weiterhin ausgeführt werden, sowie Versender
von regelmäßigen Informationstexten, so dass mit Supersedes ältere
Versionen überschrieben werden können.
Gleichzeitig haben wir die Verarbeitung von "Cancel Locks" (aka
"canlock") aktiviert. Nutzer, die im Cancel bzw. Supersedes einen
passenden Cancel-Key mitschicken, können also weiterhin ihre Artikel
auf unseren Servern löschen oder überschreiben. Unser Server fügt in
Postings unserer eigenen Nutzer automatisch einen Cancel-Lock ein; ein
eventuell bereits durch den User eingefügter Header wird gemäß den
Spezifikationen entsprechend erweitert. Cancels und Supersedes über
unseren Server erhalten nach Prüfung analog automatisch den passenden
Cancel-Key und werden ausgeführt.
Für unsere eigenen Nutzer ergibt sich als weitere wesentliche
Änderung, dass manche Artikel zukünftig mehrfach zu sehen sein werden
oder dass Artikel auf unserem Server vorhanden sind, die anderswo
nicht (mehr) existieren. Dies geschieht, wenn ein Autor seinen Artikel
löschen oder durch eine neuere Version ersetzen wollte, aber der
Cancel oder Supersedes von unserem Server nicht ausgeführt wurde, weil
wir kein zuverlässiges Kriterium hatten, um eine missbräuchliche
Verwendung auszuschließen.
Wir empfehlen allen Teilnehmern am Usenet:
* Reguläre Nutzer
o Verzichten Sie auf Cancels und verschicken Sie stattdessen
Supersedes. Dadurch erscheint auf Servern, die keine
Cancels und Supersedes ausführen, ein zweiter Artikel in
sichtbarer Nähe zum ersten, und die Leser können erkennen,
dass es zu Ihrem Artikel eine zweite, neuere Fassung gibt.
o Aktivieren Sie, so vorhanden, die Verwendung von Cancel
Lock in Ihrem Newsreader. Dieser Mechanismus stellt den
Zusammenhang zwischen dem Cancel und dem zu cancelnden
Artikel her, ohne aber - anders als bei signierten
Postings - die Möglichkeit einer Profilbildung über alle
Artikel eines Nutzers zu geben.
* Versender von regelmäßigen Informationstexten mit "Supersedes:"-Header
o Versehen Sie die Artikel, so noch nicht geschehen, mit
einem "Expires:"-Header.
o Versehen Sie die Artikel mit den Headern "Cancel-Lock:"
und "Cancel-Key:".
o Außerdem können Sie Ihre Artikel mit der üblichen
PGP-Signatur im Header versehen ("X-PGP-Sig:").
* Despammer
o Signieren Sie Cancels geeignet kryptographisch
o oder - was auf dasselbe hinausläuft - verschicken Sie
zusätzlich auch "NoCeM Notices". Diese werden von uns
ausgewertet, eventuell ist ein kurzer Hinweis an
ne...@individual.de nötig, damit der Versender in die
Konfiguration aufgenommen wird.
Wir bedauern alle Unannehmlichkeiten, die sich durch diese Umstellung
ergeben, sind aber insgesamt zuversichtlich, eine bessere Qualität im
Angebot der Newsgruppen zu erreichen. Und wir würden uns freuen, wenn
auch andere Server Mechanismen zur verbesserten Cancelverarbeitung
einführen würden, um eine nachhaltige Verbesserung für das ganze Netz
zu erzielen.
Mit freundlichen Grüßen,
NetNews-Team Individual.DE
Thomas Hochstein
> Ich benutze als NR den Agent in der aktuellen Version, was muß ich nun
> wo eintragen/ergänzen, damit ich in meinen seltenen Fällen meine
> geposteten Artikeln noch weiterhin canceln kann?
Meines Wissens beherrscht praktisch kein Newsreader - außer Gnus -
Cancel-Lock und Cancel-Key.
Alexander Bartolich
Im Changelog von slrn findet sich folgendes:
#
# Changes since 0.9.7.4
# [...]
# 10. Support Cancel-Locks using the canlock library (--with-canlock) that can
# be obtained from <http://cssri.meowing.net/>; you also need to set the
# new variable "cansecret_file" to a file containing your Cancel-Lock
# password to enable this (based on a patch by Andreas Barth).
Die angegebene Web-Site ist tot.
Es gibt aber aktuelle Debian-Pakete dafür, d.h.
apt-get install libcanlock2 libcanlock2-dev
klappt mit Sarge und Etch. Mal sehen.
Sven Hartge
tin kann es auch. (Siehe Header.)
S°
--
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/
Sven Hartge
tin kann es auch. (Siehe Header.)
Nils Ketelsen
> Thomas Hochstein <t...@inter.net> wrote...
>> Meines Wissens beherrscht praktisch kein Newsreader - außer Gnus -
>> Cancel-Lock und Cancel-Key.
> slrn und tin, unter Umständen muß aber neu übersetzt werden.
Also die nicht ganz kleine Gruppe von Leuten, die so Dinge wie eine
grafische Oberfläche nutzen (und nicht den Newsserver der FU) werden keinen
Cancel mehr durchbekommen (auf dem newsserver der FU).
Naja, mal sehen, zu wieviel zusätzlichen Meta-Diskussionen ("das posting auf
das Du geantwortet hast gibts hier nicht" und "wieso postest Du das Doppelt,
Du <beleidigendeswort>?") das in de.all führt.
Nils
--
Newsreaders still feel it is worth a special and rather worrying mention if,
for instance, a crime was planned by people over the Internet. They don't
bother to mention when criminals use the telephone or the M4, or discuss
their dastardly plans over a cup of tea. -- Douglas Adams --
Bettina Fink
> Was müsste ich denn z.B. machen, um diesen Artikel, den ich gerade
> schreibe und über Newsoffice.de einliefern werde, canceln/superseden
> zu können, so das dieser Cancel/Supsersede auch bei individual.de
> ausgeführt wird?
Cancel-Lock und Cancel-Key verwenden. Wahlweise selbst setzen, sofern
Deine Software es unterstützt, oder Deinen Admin bitten, dass er so
eine Lösung in den Server einbaut, dass die Artikel alle automatisch
damit bestückt werden, wie wir es jetzt für Individual gemacht haben.
Es geht auch beides zusammen, also ein User-Lock und ein Server-Lock
(Zeile wird erweitert), als Key reicht dann einer von beiden.
Wie ich schon an anderer Stelle schrieb:
Sicherlich ist Cancel-Lock etwas angestaubt und nicht sehr verbreitet.
Aber es ist da und es funktioniert (leider nie RFC geworden sondern
im Draft versandet (*)).
Die Alternativen wären gewesen, die Cancel- und Supersedes-Verarbeitung
komplett abzuschalten (ist ja nur ein Buchstabe in der Konfig, also ein
echt leichter Weg) oder etwas komplett neues zu erfinden, was es noch
schwerer gehabt hätte, ausserhalb unseres Systems zu funktionieren
und beachtet zu werden.
Wir betrachten unseren Weg als guten Kompromiss, die grundsätzliche
Funktionalität von Cancel/Supsersedes beizubehalten, aber den Mißbrauch
stark einzuschränken.
(*) http://tools.ietf.org/wg/usefor/draft-ietf-usefor-cancel-lock/
Ralph Angenendt
> Sicherlich ist Cancel-Lock etwas angestaubt und nicht sehr verbreitet.
Nicht sehr verwunderlich: <http://cssri.meowing.net/>. Außerhalb von
Debian dürfte das als Paket nicht vorhanden sein (PLD von 2003 hatte da
wohl auch noch ein RPM).
Ralph
--
Der Osten ist das neue Bochum.
Nicht schreiben können: http://lestighaniker.de/
Roman Racine
> Alexander Skwar <alexand...@digitalprojects.com> wrote:
>
>> Was müsste ich denn z.B. machen, um diesen Artikel, den ich gerade
>> schreibe und über Newsoffice.de einliefern werde, canceln/superseden
>> zu können, so das dieser Cancel/Supsersede auch bei individual.de
>> ausgeführt wird?
> Sicherlich ist Cancel-Lock etwas angestaubt und nicht sehr verbreitet.
> Aber es ist da und es funktioniert (leider nie RFC geworden sondern
> im Draft versandet (*)).
> (*) http://tools.ietf.org/wg/usefor/draft-ietf-usefor-cancel-lock/
Ich habe den Draft durchgelesen und konnte mittlerweile auch die Ergebnisse
reproduzieren. So ganz klar und eindeutig ist das Verfahren ja nicht
definiert. So steht in der Definition von Cancel-Key dass dort der
Base64-codierte Input für den Hashalgorithmus stehen soll.
In den Beispielen unten ist er aber z.T. auch uncodiert ... Was gilt denn
jetzt nun in der Praxis?
Gruss
Roman°
--
IRC-Freenode: #usenet-friends
http://www.usenet-friends.ch.vu/
Lutz Frommberger
> tin kann es auch. (Siehe Header.)
Da darf man aber in der Doku erstmal ordentlich suchen. Im ersten Anlauf
habe ich außer
changelog.Debian.gz: * Enabled cancel locks support.
und
${TIN_HOMEDIR-"$HOME"}/.cancelsecret
secret to be used for canlocks
noch nichts gefunden.
Aber tin ist ja eh kein Einsteiger-Newsreader.
gruß,
--
Lutz Frommberger | "Wenn ist das Nunstück git und
| Slotermeyer? Ja! ... Beiherhund
http://www.aussagekraft.de | das Oder die Flipperwaldt
pgp key on request | gersput." - Ernest Scribbler
Bodo Moeller
> Bettina Fink wrote:
>> Sicherlich ist Cancel-Lock etwas angestaubt und nicht sehr verbreitet.
>> Aber es ist da und es funktioniert (leider nie RFC geworden sondern
>> im Draft versandet (*)).
>
>> (*) http://tools.ietf.org/wg/usefor/draft-ietf-usefor-cancel-lock/
> Ich habe den Draft durchgelesen und konnte mittlerweile auch die Ergebnisse
> reproduzieren. So ganz klar und eindeutig ist das Verfahren ja nicht
> definiert. So steht in der Definition von Cancel-Key dass dort der
> Base64-codierte Input für den Hashalgorithmus stehen soll.
Nein, das steht da nicht. Der Codestring im Cancel-Key besteht zwar
aus Base-64-Oktetten und ist irgendein ein base-64-codierter String,
aber dabei wird nicht der SHA-1-Input codiert - sondern SHA-1 soll
ausdrücklich auf den Codestring selbst angewandt werden.
Die Beispiele kommen alle hin:
< 6. Examples
<
< The following are Cancel-Lock headers along with a Cancel-Key header
< that matches them:
<
< Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4=
< Cancel-Key: sha1:aaaBBBcccDDDeeeFFF
$ echo -n aaaBBBcccDDDeeeFFF | openssl sha1 -binary | openssl base64
bNXHc6ohSmeHaRHHW56BIWZJt+4=
< Cancel-Lock: SHA1:H7/zsCUemvbvSDyARDaMs6AQu5s=
< Cancel-Key: sha1:chW8hNeDx3iNUsGBU6/ezDk88P4= sha1:4srkWaRIzvK51ArAP
$ echo -n chW8hNeDx3iNUsGBU6/ezDk88P4= | openssl sha1 -binary | openssl base64
H7/zsCUemvbvSDyARDaMs6AQu5s=
$ echo -n 4srkWaRIzvK51ArAP | openssl sha1 -binary | openssl base64
s5lo9uclmurmWaCRI2DtYWsmBC4=
< Cancel-Lock: sha1:JyEBL4w9/abCBuzCxMIE/E73GM4=
< sha1:2Bmg+zWaY1noRiCdy8k3IapwSDU=
< Cancel-Key: sha1:K4rkWRjRcXmIzvK51ArAP
$ echo -n K4rkWRjRcXmIzvK51ArAP | openssl sha1 -binary | openssl base64
JyEBL4w9/abCBuzCxMIE/E73GM4=
Mehrere Einträge im Header Cancel-Lock oder Cancel-Key kann es
deswegen geben, weil mehrere Seiten hier etwas zu sagen haben können:
Zunächst der Artikel-Autor (oder sein Newsreader), dann ggf. der
Moderator und schließlich der Newsserver, bei dem das Ganz per POST
landet. Einer der Keys muß zu einem der Locks passen.
Der Newsserver kann z.B. aus einem geheimen Schlüssel, dem Usernamen
laut Benutzerauthentisierung und der Message-ID (des jeweiligen
Artikels für Cancel-Lock, des zu löschenden Artikels bei Cancel-Key)
automatisch Cancel-Locks und bei Bedarf dazu passende Cancel-Keys
erzeugen. Damit kann der Server automatisch den Cancel-Key
rekonstruieren, ohne sich dafür den zu löschenden Artikel ansehen zu
müssen (der lokal vielleicht schon durch Expire verschwunden ist).
Thomas Hochstein
> [...] oder Deinen Admin bitten, dass er so
> eine Lösung in den Server einbaut, dass die Artikel alle automatisch
> damit bestückt werden, wie wir es jetzt für Individual gemacht haben.
Was natürlich die interessierte Frage nach sich zieht, wie
news.indidivual.de das technisch gelöst hat, und ob man diese Lösung
auf einem unmodifizierten INN übernehmen kann. :)
-thh
Bettina Fink
>> tin kann es auch. (Siehe Header.)
>
> Da darf man aber in der Doku erstmal ordentlich suchen. Im ersten Anlauf
> habe ich außer
>
> changelog.Debian.gz: * Enabled cancel locks support.
>
> und
>
> ${TIN_HOMEDIR-"$HOME"}/.cancelsecret
> secret to be used for canlocks
>
> noch nichts gefunden.
Ist nicht schwer; ich habe es eben erst für meinen eigenen tin (1.9.2
kompiliert auf Fedora 7) gemacht, weil ich vorher noch nicht dazu kam),
steht auch haarklein im INSTALL-File:
1. in den ausgepackten Sourcen in das Unterverzeichnus "libcanlock"
wechseln, "./Build"
2. dann ganz normal im Hauptverzeichnis "configure" mit den normalen
Optionen durchlaufen lassen, Cancel-Lock braucht da nichts extra
3. nach dem "configure" noch src/Makefile anpassen: CANLOCK sowie
CANLIB einkommentieren (nein, ich weiss nicht, was -DEVIL_INSIDE
bei CANLOCK macht und habe es auch nicht im Source nachgeguckt; ich
habe es einfach auskommentiert gelassen und nur -DUSE_CANLOCK
einkommentiert)
4. kompilieren, installieren, fertig
Achja, natürlich noch irgendwas lustiges in ~/.cancelsecret schreiben.
Holger Marzen
Ein freches
hm@maus:~$ strings /usr/bin/slrn | grep cansecret
cansecret_file
macht mir bei Debian Etch Hoffnung. Muss mich mal einlesen, wie die
Sache funktioniert.
Roman Racine
> Roman Racine <roman....@gmx.de>:
>> Bettina Fink wrote:
>
>>> Sicherlich ist Cancel-Lock etwas angestaubt und nicht sehr verbreitet.
>>> Aber es ist da und es funktioniert (leider nie RFC geworden sondern
>>> im Draft versandet (*)).
>>
>>> (*) http://tools.ietf.org/wg/usefor/draft-ietf-usefor-cancel-lock/
>
>> Ich habe den Draft durchgelesen und konnte mittlerweile auch die
>> Ergebnisse reproduzieren. So ganz klar und eindeutig ist das Verfahren ja
>> nicht definiert. So steht in der Definition von Cancel-Key dass dort der
>> Base64-codierte Input für den Hashalgorithmus stehen soll.
>
> Nein, das steht da nicht. Der Codestring im Cancel-Key besteht zwar
> aus Base-64-Oktetten und ist irgendein ein base-64-codierter String,
> aber dabei wird nicht der SHA-1-Input codiert - sondern SHA-1 soll
> ausdrücklich auf den Codestring selbst angewandt werden.
Stimmt, dann geht alles auf. Danke für den Hinweis.
Sascha Grage
> D.h. wenn ich, so wie jetzt, über individual einliefere, dann kann ich
> auch weiterhin ganz einfach so wie bisher canceln?
Ja.
,------------ [ Posting ]
| From: Sascha Grage <SGr...@gmx.net>
| Newsgroups: ger.ct.test
| Subject: hallo -ignore-
| Message-ID: <f60r74...@freakm941.homelinux.com>
| Cancel-Lock: sha1:u3lJ4HTPqbdVMFBEeZj+LKoaWjk=
`------------
,-------- [ Cancel ]
| From: Sascha Grage <SGr...@gmx.net>
| Newsgroups: ger.ct.test
| Subject: Cancel "hallo -ignore-"
| Control: cancel <f60r74...@freakm941.homelinux.com>
| Message-ID: <f60ria...@freakm941.homelinux.com>
| Cancel-Lock: sha1:gzV1w/Sjdn/yijxxELgkLB2yTww=
| Cancel-Key: sha1:BRvKtsOFjSkCTy6hMIX1uR0ml7o=
`------------
Gruß,
Sascha
--
Beer is proof that God loves us and wants us to be happy...
(c)
np: Phonique @ Resident Sputnik 23.06.2007 - Phonique
Sascha Grage
> Aber dem Betreiber von Newsoffice kann man wohl kaum auffordern, seine
> Cancels jetzt so auszuführen, wie individual es gerne hätte. Zumal er
> die ganze Sache ja eh schon völlig unentgeltlich macht.
Warum nicht? Frage doch einfach mal in newsoffice.support nach. Björn ist ja
äh, sehr hilfsbereit... ;-)
Gruß,
Sascha
--
Beer is proof that God loves us and wants us to be happy...
(c)
np: Phonique @ Resident Sputnik 23.06.2007 www.dj-y-the-one.de - Phonique
Peter Schwindt
> Ein freches
>
> hm@maus:~$ strings /usr/bin/slrn | grep cansecret
> cansecret_file
>
> macht mir bei Debian Etch Hoffnung. Muss mich mal einlesen, wie die
> Sache funktioniert.
Obige Variable in .slrnrc definieren und auf eine Datei zeigen lassen.
Dort einfach nur das gewünschte Passwort ablegen, ferti.cz
Roman Racine
Ich hab mal das Perl-Modul News::Article um Cancel-Key-Handling ergänzt, ein
diff zur Version 1.27 ist hier zu finden sowie am Ende dieses Postings:
http://www.trash.net/~roman/weiteres/Article.pm.diff
Vorausgesetzt, man hat eine Datenbank, eine Funktion oder was auch immer,
welche den Inhalt des Cancel-Key-Headers erzeugt, kann man mit
$article->create_cancel_lock($cancel_key)
einen dazu passenden Cancel-Lock Header erzeugen und den im Posting
mitgeben.
Mit $article->create_cancel_key($cancel_key)
wird für ein Posting, welches ein anderes Posting löschen oder überschreiben
soll, der entsprechende Header gesetzt. Die Verwaltung der Cancel-Keys ist
Sache des Users (z.B. mittels Datenbank, oder mit einer Funktion basierend
auf der Message-ID).
Mit $article->verify_cancel_lock($oldposting)
wird überprüft, ob der eingegangene Artikel $article einen gültigen
Cancel-Key Header hat, um $oldposting zu überschreiben oder zu löschen.
Gruss
Roman°
=========== Article.pm.diff (Zeilenumbrüche z.T. kaputt) =============
1435a1436,1533
>
> =item verify_cancel_lock(ARTICLE)
>
> Verifies, if a Cancel-Key header is set in this posting and if
> it matches the Cancel-Lock header given in ARTICLE using the
> algorithms described in
> http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01
>
> ARTICLE is a reference to a News::Article object.
>
> returns 1 if the Cancel-Key header matches the Cancel-Lock header given
> in ARTICLE.
>
> returns 0 if one of these headers does not exist or if they don't match.
>
> =cut
>
>
> sub verify_cancel_lock {
> my ($self,$tocancel) = @_;
> if (!defined $tocancel->header('Cancel-Lock')
> or !defined $self->header('Cancel-Key')
> ) {
> return 0;
> }
> my %locks;
> for my $lock (split(/\s+/,$tocancel->header('Cancel-Lock'))) {
> if ($lock =~ /^sha1:(\S+)/i) {
> $locks{$1} = 1;
> }
> }
> if (%locks eq '0') {
> return 0;
> }
>
> for my $key (split(/\s+/,$self->header('Cancel-Key'))) {
> if ($key=~ /^sha1:(\S+)/i) {
> if (exists $locks{$self->generate_cancel_lock($1)}) {
> return 1;
> }
> }
> }
> return 0;
> }
>
>
> =item create_cancel_lock(CANCEL_KEY)
>
> Creates a valid Cancel-Lock header, given a cancel key and adds
> it to the header. CANCEL_KEY is a string.
>
> See http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01
> for details.
>
> A cancel key must consist out of base64-octets and must be genereated
> by the user. A possible algorithm to generate cancel keys is
> SHA1(fixed secret value||Message-ID).
>
> =cut
>
>
> sub create_cancel_lock {
> my ($self,$cancel_key) = @_;
> if (defined $self->header('Cancel-Lock')) {
> $self->set_headers('Cancel-Lock',
> $self->header('Cancel-Lock') . "\n sha1:"
> . $self->generate_cancel_lock($cancel_key)
> );
> } else {
> $self->set_headers('Cancel-Lock',"sha1:" .
$self->generate_cancel_lock($cancel_key));
> }
> }
>
> =item create_cancel_key(CANCEL_KEY)
>
> Creates a valid Cancel-Key header, given a cancel key and adds
> it to the header. CANCEL_KEY is a string.
>
> See http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01
> for details.
>
> A cancel key must consist out of base64-octets and must be genereated
> by the user. A possible algorithm to generate cancel keys is
> SHA1(fixed secret value||Message-ID).
>
> =cut
> sub create_cancel_key {
> my ($self,$cancel_key) = @_;
> if (defined $self->header('Cancel-Key')) {
> $self->set_headers('Cancel-Key',
> $self->header('Cancel-Key') . "\n sha1:" .
> $cancel_key
> );
> } else {
> $self->set_headers('Cancel-Key',"sha1:" . $cancel_key);
> }
> }
>
1563a1662,1682
>
>
> # Generates a Cancel-Lock, given the input Cancel-Key
> # Note that Cancel-Key must use Base64 characters
> # to fit in the header
> #
> # Relies on MIME::Base64 and Digest::SHA1
>
> sub generate_cancel_lock;
> use MIME::Base64;
> use Digest::SHA1;
>
> ; sub generate_cancel_lock {
> my ($self,$string) = @_;
> my $returnstring = MIME::Base64::encode_base64(Digest::SHA1::sha
($string));
> chomp $returnstring;
> return $returnstring;
>
> }
>
>
Alexander Bartolich
Die gute Nachricht: Funktioniert auch mit Debian Sarge.
Außerdem lassen sich canlock2b und slrn-0.9.8.1pl1 problemlos
unter Fedora 7 x86_64 übersetzen.
Vorsicht Falle: Die Option
set cansecret_file .cansecret
bleibt ohne jede Meldung einfach wirkungslos, wenn man zusätzlich
set generate_message_id 0
eingetragen hat.
Lässt man slrn dann Message-IDs generieren braucht man
posting_host hostname
damit zumindest der FQDN wieder gut aussieht.
Besser ist es, auf
set use_recommended_msg_id 1
umzustellen.
Alexander Bartolich
Die gute Nachricht: Funktioniert auch mit Debian Sarge.
Heiko Schlichting
Technische Lösung:
Wir haben unseren nnrpd-Source so modifiziert, dass die entsprechenden
Header eingebaut werden. Dazu haben wir auf auf die libcanlock
zurückgegriffen, die ja als ...orig.tar.gz dem Debian-Source-Paket beiliegt
und auch auf IRIX funktioniert.
Die Übernahme unserer Änderungen auf einen unmodifizierten INN ist nicht
möglich, weil unser nnrpd dem Original nicht mehr sehr ähnlich ist. Das
Einfügen der entsprechenden Header sind nur wenige Zeilen, aber vorher muss
ja die Identität des Users überprüft und sichergestellt werden, dass
Artikel und Cancel-Nachricht von der gleichen Identität stammen. Bei
unserem nnrpd gibt es dafür eine entsprechende Funktion, aber ich fürchte,
in einem unmodifizierten INN gibt es sowas nicht. Sorry, aber ich habe den
Original-Source von nnrpd seit vielen Jahren nicht mehr genau angesehen.
Heiko
Thomas Hochstein
>> Was natürlich die interessierte Frage nach sich zieht, wie
>> news.indidivual.de das technisch gelöst hat, und ob man diese Lösung
>> auf einem unmodifizierten INN übernehmen kann. :)
>
> Technische Lösung:
> Wir haben unseren nnrpd-Source so modifiziert,
Das hatte ich befürchtet. :)
> dass die entsprechenden
> Header eingebaut werden. Dazu haben wir auf auf die libcanlock
> zurückgegriffen, die ja als ...orig.tar.gz dem Debian-Source-Paket beiliegt
> und auch auf IRIX funktioniert.
>
> Die Übernahme unserer Änderungen auf einen unmodifizierten INN ist nicht
> möglich, weil unser nnrpd dem Original nicht mehr sehr ähnlich ist. Das
> Einfügen der entsprechenden Header sind nur wenige Zeilen, aber vorher muss
> ja die Identität des Users überprüft und sichergestellt werden, dass
> Artikel und Cancel-Nachricht von der gleichen Identität stammen. Bei
> unserem nnrpd gibt es dafür eine entsprechende Funktion, aber ich fürchte,
> in einem unmodifizierten INN gibt es sowas nicht.
Mein erster Gedanke ins Unreine war, das im Rahmen der filter_nnrpd.pl
zu lösen; dort hat man ja Zugriff auf die Userkennung. Und wenn es
genügen würde, für Cancel-Lock und Cancel-Key Zugriff auf ein für
diesen User gespeichertes secret zu haben, ohne den zu cancelnden
Artiekl zu kennen, würde das vielleicht reichen - falls versucht wird,
einen "falschen" Artikel zu canceln, paßt dann halt der Key nicht aufs
Lock.
Ich fuppe das mal zur Technik rüber. :)
-thh
Robert Grimm
> Vorsicht Falle: Die Option
> set cansecret_file .cansecret
> bleibt ohne jede Meldung einfach wirkungslos, wenn man zusätzlich
> set generate_message_id 0
> eingetragen hat.
> Lässt man slrn dann Message-IDs generieren braucht man
> posting_host hostname
> damit zumindest der FQDN wieder gut aussieht.
> Besser ist es, auf
> set use_recommended_msg_id 1
> umzustellen.
Egal wie, mein slrn (cvs) schreibt den Cancel-Lock: header zweimal, und
leafnode mag das dann nicht verschicken. Durch auskommentieren von zwei
Zeilen in post.c lässt sich das vermeiden, allerdings hab ich dann
Header wie:
#v+
Cancel-Lock: sha1:10UBThuUR+LF5BqF7lXdU1cSKgM= sha1:0w9d3ZLDBkxYDdVtGHNDFAQgwiY=
#v-
der für mich nicht ganz richtig aussieht.
Oder ist der zweite string der von Individual eingefügte und das wäre richtig?
Muß ich nochmal schauen.
Ein supersede mit obigem hat zumindest funktioniert..
Mein Spieltrieb liegt jetzt erstmal bis Montag auf Eis...
xpost und followup nach dcsn,
Rob
--
A right is not what someone gives you;
it's what no one can take from you.
-- Ramsey Clark
Paul Muster
> Gleichzeitig haben wir die Verarbeitung von "Cancel Locks" (aka
> "canlock") aktiviert. Nutzer, die im Cancel bzw. Supersedes einen
> passenden Cancel-Key mitschicken, können also weiterhin ihre Artikel
> auf unseren Servern löschen oder überschreiben. Unser Server fügt in
> Postings unserer eigenen Nutzer automatisch einen Cancel-Lock ein; ein
> eventuell bereits durch den User eingefügter Header wird gemäß den
> Spezifikationen entsprechend erweitert. Cancels und Supersedes über
> unseren Server erhalten nach Prüfung analog automatisch den passenden
> Cancel-Key und werden ausgeführt.
Ein leafnode-"Server" sieht für euch aus wie ein Client. Daher bekommen
alle darüber bei euch eingelieferten Postings ein Cancel-Lock als seien
sie von einem User. Daraus folgt dann, dass mehrere Nutzer "hinter"
demselben leafnode (sofern sie nicht selbst im Client ein Cancel-Lock
setzen) gegenseitig ihre Posting canceln und superseden können.
Richtig?
Nein, ich halte das nicht für ein Problem, sondern möchte es einfach
wissen/verstehen.
Danke & mfG Paul, wg. Richtungswechsel Gruppenliste und Followup-To:
angepasst
Bodo Moeller
> Wir haben unseren nnrpd-Source so modifiziert, dass die entsprechenden
> Header eingebaut werden. Dazu haben wir auf auf die libcanlock
> zurückgegriffen, die ja als ...orig.tar.gz dem Debian-Source-Paket beiliegt
> und auch auf IRIX funktioniert.
>
> Die Übernahme unserer Änderungen auf einen unmodifizierten INN ist nicht
> möglich, weil unser nnrpd dem Original nicht mehr sehr ähnlich ist. Das
> Einfügen der entsprechenden Header sind nur wenige Zeilen, aber vorher muss
> ja die Identität des Users überprüft
Ja.
> und sichergestellt werden, dass
> Artikel und Cancel-Nachricht von der gleichen Identität stammen.
Nein, das müßte man eigentlich nicht: Wer den Key nicht aus einem
Geheimnis und der Message-ID berechnet, sondern aus Geheimnis,
Message-ID und User-Identität, kann sich solche Kontrollen im Grunde
sparen. Die Kontrolle geschieht dann erst anhand von Cancel-Key und
Cancel-Lock beim Ausführen der Löschung. (So können zwar ungültige
Cancels oder Supersedes in die Welt gesetzt werden, wenn die Identität
nicht zu der des Ursprungs-Artikels paßt - aber Artikel mit
unwirksamen Cancel-Keys könnte der User auch über einen anderen Server
einspeisen.)
Heiko Schlichting
> Heiko Schlichting <he...@cis.fu-berlin.de>:
>> [...] und sichergestellt werden, dass
>> Artikel und Cancel-Nachricht von der gleichen Identität stammen.
>
Laut Canlock-Draft schon:
| If, as mentioned in 3.1 an injecting agent (or moderator) has added
| a "Cancel-Lock:" header to an article listed in the "Cancel:",
| "Replaces:" or "Supersedes:" headers then (assuming it authenticates the
| poster as being the same as the poster of the original article(s)) it
| MUST add a "Cancel-Key: " header with the cancel-key(s) that correspond
| to those article(s).
|
| Other Agents MUST NOT alter this header.
> Wer den Key nicht aus einem Geheimnis und der Message-ID berechnet,
> sondern aus Geheimnis, Message-ID und User-Identität, kann sich solche
> Kontrollen im Grunde sparen.
Damit folgt man nicht dem Draft und erzeugt ungültige Cancel-Key Header.
Das ist sicherlich alles andere als schön und sauber, aber ich gebe Dir
Recht, dass das vermutlich funktionieren würde. Mit etwas mehr Aufwand
könnte man auch den Cancel-Lock des alten Artikels gegenprüfen und
Cancel-Key nur einbauen, wenn es zum Ursprungsartikel passt. Wie man sich
verhält, wenn der Originalartikel nicht mehr da ist, kann man sich dann
immer noch aussuchen, aber das wird ja nicht der Normalfall sein.
Heiko
Bodo Moeller
>>> [...] und sichergestellt werden, dass
>>> Artikel und Cancel-Nachricht von der gleichen Identität stammen.
>> Nein, das müßte man eigentlich nicht [...]
> Laut Canlock-Draft schon:
>
> | If, as mentioned in 3.1 an injecting agent (or moderator) has added
> | a "Cancel-Lock:" header to an article listed in the "Cancel:",
> | "Replaces:" or "Supersedes:" headers then (assuming it authenticates the
> | poster as being the same as the poster of the original article(s)) it
> | MUST add a "Cancel-Key: " header with the cancel-key(s) that correspond
> | to those article(s).
> |
> | Other Agents MUST NOT alter this header.
Diese Bestimmung schließt meinen Vorschlag nicht aus. Das MUST, falls (!)
der Poster der gleiche ist, wird nämlich automatisch erfüllt.
>> Wer den Key nicht aus einem Geheimnis und der Message-ID berechnet,
>> sondern aus Geheimnis, Message-ID und User-Identität, kann sich solche
>> Kontrollen im Grunde sparen.
> Damit folgt man nicht dem Draft und erzeugt ungültige Cancel-Key Header.
> Das ist sicherlich alles andere als schön und sauber, aber ich gebe Dir
> Recht, dass das vermutlich funktionieren würde.
Eben. Und daß es durchaus auch mal ungültige Einträge in Cancel-Key-Headern
geben darf, zeigt eins der Beispiele im Canlock-Draft.
> Mit etwas mehr Aufwand
> könnte man auch den Cancel-Lock des alten Artikels gegenprüfen und
> Cancel-Key nur einbauen, wenn es zum Ursprungsartikel passt.
ACK: Wenn sich diese Prüfung durchführen läßt, ist sie nicht verkehrt.
> Wie man sich
> verhält, wenn der Originalartikel nicht mehr da ist, kann man sich dann
> immer noch aussuchen, aber das wird ja nicht der Normalfall sein.
Gerade als Lösung auch für den Fall, daß beim canlockenden Server
selbst keine Information mehr über den Originalartikel vorliegt, ist
mein Vorschlag gedacht - damit ein Supersedes nicht auf Fremdservern
unbeachtet bleibt, bloß weil der Heimatserver sich nicht mehr daran
erinnern kann, daß der zu löschende Artikel tatsächlich von mir
gepostet wurde.
Heiko Schlichting
>> | a "Cancel-Lock:" header to an article listed in the "Cancel:",
>> | "Replaces:" or "Supersedes:" headers then (assuming it authenticates the
>> | poster as being the same as the poster of the original article(s)) it
>> | MUST add a "Cancel-Key: " header with the cancel-key(s) that correspond
>> | to those article(s).
>> |
>> | Other Agents MUST NOT alter this header.
>
> Diese Bestimmung schließt meinen Vorschlag nicht aus. Das MUST, falls (!)
> der Poster der gleiche ist, wird nämlich automatisch erfüllt.
Aber "Other Agents MUST NOT alter this header" ist nicht erfüllt, wenn
"assuming it authenticates the poster as being the same as the poster of
the original article" nicht zutrifft und es sich daher um einen "other
agent" handelt.
Heiko
Wolfgang Becker
> Da darf man aber in der Doku erstmal ordentlich suchen. Im ersten Anlauf
> habe ich außer
Gibt es noch mehr?
> Aber tin ist ja eh kein Einsteiger-Newsreader.
Zum Glück hat mir das als ich Einsteiger war keiner gesagt hat.
Tschüß,
Wolfgang
--
Wolfgang Becker *** eMail ua...@gmx.de *** http://uafr.freeshell.org/
Lutz Frommberger
> Lutz Frommberger <Lutz.Fro...@gmx.de> wrote:
>> Da darf man aber in der Doku erstmal ordentlich suchen. Im ersten Anlauf
>> habe ich außer
>
> Gibt es noch mehr?
Mehr Anläufe? Glaube nicht. Wahrscheinlich reichts, was in
~/.cancelsecret reinzuschreiben. Aber mir ist es eigentlich recht
egal, ob in Berlin meine Cancels ankommen oder nicht.
>> Aber tin ist ja eh kein Einsteiger-Newsreader.
>
> Zum Glück hat mir das als ich Einsteiger war keiner gesagt hat.
Wenn ich uafr richtig interpretiere und das genauso lang her ist
wie un43 bei mir, dann wundert mich das nicht. Ich bin dennoch
nicht mit tin eingestiegen.
Thomas Hochstein
> Ein leafnode-"Server" sieht für euch aus wie ein Client. Daher bekommen
> alle darüber bei euch eingelieferten Postings ein Cancel-Lock als seien
> sie von einem User.
Für Individual - und vertraglich - *sind* sie ja auch von einem User.
Individual erlaubt es zwar, lokale Newsserver zu verwenden, für alles,
was darüber geschieht, ist aber der Individual-Accountinhaber der
Verantwortliche und der Ansprechpartner. Demzufolge ist es sogar
irgendwo logisch, daß er dann auch alles, was über seinen Account
läuft, canceln darf.
> Daraus folgt dann, dass mehrere Nutzer "hinter"
> demselben leafnode (sofern sie nicht selbst im Client ein Cancel-Lock
> setzen) gegenseitig ihre Posting canceln und superseden können.
Ack.
-thh
FUp2 ignoriert, weil meine Antwort sich nicht primär auf die Technik
bezieht.
Bodo Moeller
"Other agents" im dritten Absatz lese ich hier allgemeiner als
Gegensatz zum "posting agent" (erster Absatz) oder "injecting agent"
(zweiter Absatz): Ein "posting agent" oder "injecting agent" darf
etwas am Cancel-Key-Header machen, ein bloßer "relaying agent" oder
"serving agent" nicht. Vergleich auch den Aufbau von Abschnitt 3.1 in
draft-ietf-usefor-cancel-lock-01.txt
Sicherlich hat der Draft-Autor einen Ansatz wie meinen gar nicht im
Sinn gehabt, so daß es mehr oder weniger Zufall ist, ob der Text jetzt
Deine oder meine Lesart hergibt. Sprachlich ist meine aber voll und
ganz gerechtfertigt - die von Dir genannten Einschränkungen bis hin
zum "assuming" stehen ja nicht als "defining relative clause", die die
Bedeutung von "injecting agent" als Subjekt einschränken würden.
Vielmehr beschreibt der Satz ein Regel, die als solche für jeden
"injecting agent" gilt - erst wegen ihrem "if" und "assuming"
ist der "then"-Teil nicht immer anzuwenden.
Und technisch hat mein Ansatz durchaus etwas für sich: Bei Eurem
Serverdesign könnt Ihr Euch zwar offenbar sehr gut anders behelfen, so
daß Ihr keinen Bedarf für die vorgeschlagene Konstruktion habt; bei
anderen Servern muß das aber nicht so sein. Es geht darum, daß ein
wirksamer Cancel oder Supersedes auch dann auf den Weg geschickt
werden kann, wenn der "injecting agent" keinen Zugriff mehr auf den
jetzt zu löschenden Artikel (oder auch nur auf ausgewählte
Detailinformation dazu) hat, sei es nach einem Expire oder weil der
"injecting agent" von der Artikeldatenbank von vornherein separat
gehalten wird.
Roman Racine
> Christoph Biedl <cbi...@gmx.de> wrote:
>
>> In diesem Kontext war
>> >> Dem sollte jetzt so sein, bitte mal ausprobieren.
>> zu verstehen.
>
> Ach so. Ich soll mal über newsoffice canceln? Cool, mach ich sofort.
>
> So, ich habe jetzt <f5lec2...@mausi.schnauze-sonst-beule.de> über
> newsoffice gecancelt. Nur leider kann ich selber nicht überpüfen, ob der
> Cancel durchging, weil ich nicht weiß, wie ich das Posting aus dem
> Hamster loswerde. Schaust du bitte mal?
************
Path: news.albasani.net!fu-berlin.de!newsoffice.de!not-for-mail
From: kath...@rrr.de (Kathinka Wenz)
Newsgroups: de.alt.fan.rrr
Subject: cmsg cancel <f5lec2...@mausi.schnauze-sonst-beule.de>
Control: cancel <f5lec2...@mausi.schnauze-sonst-beule.de>
Date: Sun, 01 Jul 2007 14:05:32 +0200
Organization: Newsoffice.de - http://www.newsoffice.de
Lines: 2
Sender: kath...@rrr.de (Kathinka Wenz)
Message-ID: <f685ac$lq6$1...@localhost.localdomain>
References: <v68g73h29r0rab0sf...@4ax.com>
<3d6s735j6v19u1dse...@4ax.com>
<f5lec2...@mausi.schnauze-sonst-beule.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: localhost.localdomain 1183291532 22342 127.0.0.1 (1 Jul 2007
12:05:32 GMT)
X-Complaints-To: use...@localhost.localdomain
NNTP-Posting-Date: Sun, 1 Jul 2007 12:05:32 +0000 (UTC)
User-Agent: NewsPortal 0.23
Xref: news.albasani.net control.cancel:3085678
Cancelled by Newsoffice.de
**********************
Der Cancel ist auf news.individual.de ausgeführt worden. Etwas hässlich ist
dagegen die Message-ID, die Newsoffice verwendet. Was spricht eigentlich
dagegen, die Admins von Newsoffice davon zu überzeugen, den
Cancel-Lock-Mechanismus einzuführen? In de.comm.software.newsreaders ist ja
nun auch Software für INN aufgetaucht.
Gruss
Roman
--
IRC-Freenode: #usenet-friends
http://www.usenet-friends.ch.vu/
Alexander Bartolich
> Bodo Moeller <bmoe...@acm.org> wrote:
>> [...]
>> Wer den Key nicht aus einem Geheimnis und der Message-ID berechnet,
>> sondern aus Geheimnis, Message-ID und User-Identität, kann sich solche
>> Kontrollen im Grunde sparen.
>
> Damit folgt man nicht dem Draft und erzeugt ungültige Cancel-Key Header.
> Das ist sicherlich alles andere als schön und sauber, aber ich gebe Dir
> Recht, dass das vermutlich funktionieren würde.
Wenn man (für INN) die Überprüfung des Cancel-Key in filter_nnrpd.pl
einbaut (weil man dort recht einfach Zugriff auf den Newsspool hat),
dann betrifft das auch lokal eingespeiste Artikel.
Das heißt, in filter_nnrpd.pl gibt man dem Cancel-Posting einen Key,
der nur auf $User gesendete Postings passt. Und in filter_nnrpd.pl
rejected man dann dieses Cancel-Posting, falls kein Key passt. Die
Peers bekommen es in diesem Fall nie zu sehen.
Ein beobachtbare Abweichung vom im draft beschriebenen Verhalten
gibt es nur, wenn zufällig der automatisch generierte Key zu einem
anderen Lock passt.
Thomas Hochstein
>> Ansonsten aber: Die einzige Alternative war, die
>> Cancelverarbeitung komplett abzuschalten.
>
> Naja, man hätte es auch so lassen können.
Das war - aus Sicht von Individual aufgrund der Spamcancelflut in
manchen Gruppen - keine Alternative.
> Es hilft auch nicht viel, wenn einzelne Server keine Cancels mehr
> verarbeiten.
Die Anzahl nimmt deutlich zu.
> Trotz oder eigentlich wegen der vielen Missbrauchsmöglichkeiten ist mir
> Usenet lieber als jedes Forum. Weil es eben völlig unzensiert ist.
Dafür wichtig ist, daß Fremdcancel nicht - dauerhaft - möglich sind.
Sonst ist Usenet sehr wohl schnell zensiert. :)
Grüße,
-thh
Alexander Bartolich
>> sondern aus Geheimnis, Message-ID und User-Identität, kann sich solche
>> Kontrollen im Grunde sparen.
>
> Damit folgt man nicht dem Draft und erzeugt ungültige Cancel-Key Header.
> Das ist sicherlich alles andere als schön und sauber, aber ich gebe Dir
> Recht, dass das vermutlich funktionieren würde.
Wenn man (für INN) die Überprüfung des Cancel-Key in filter_nnrpd.pl
einbaut (weil man dort recht einfach Zugriff auf den Newsspool hat),
dann betrifft das auch lokal eingespeiste Artikel.
Das heißt, in filter_nnrpd.pl gibt man dem Cancel-Posting einen Key,
der nur für von $User gesendete Postings passt. Und in filter_nnrpd.pl
rejected man dann dieses Cancel-Posting, falls kein Key passt. Die
Peers bekommen es in diesem Fall nie zu sehen.
Ein beobachtbare Abweichung von dem im Draft beschriebenen Verhalten
gibt es nur, wenn zufällig der automatisch generierte Key zu einem
anderen Cancel-Lock passt.
Ulrich F. Heidenreich
>Boris 'pi' Piwinger wrote:
>
>> Letzerer Artikel hätte ersteren wegräumen sollen. Ich konnte
>> ihn aber gerade noch abrufen.
>
>Im ersten seh ich aber kein Cancel-Lock. Das dürfte der Fehler sein.
a) Dürfte Boris davon ausgegangen sein, daß er unter "Versender
von regelmäßigen Informationstexten" fällt und deshalb keine
Cancel-Lock-Header zu erzeugen braucht.
b) Was soll eigentlich dieser ganze Driet hier in dcp.status?
Könnten sich *alle* Beteiligten nicht endlich mal darauf besinnen,
daß man hier eigentlich nur über *Störungen* informiert werden will
und nicht, welche Säcke Reis bei individual umgefallen sind.
CU!
Ulrich - F'up de.comm.provider.usenet
Boris 'pi' Piwinger
>Ulrich - F'up de.comm.provider.usenet
Ich gestehe, nicht darauf geachtet zu haben. Das F'up des
Originalartikels war so unsinnig gewählt.
pi
--
Attachment? Nein: http://piology.org/ILOVEYOU-Signature-FAQ.html
begin LOVE-LETTER-FOR-YOU.txt.vbs
I am a signature virus. Distribute me until the bitter
end
Boris 'pi' Piwinger
>> Letzerer Artikel hätte ersteren wegräumen sollen. Ich konnte
>> ihn aber gerade noch abrufen.
>
>Im ersten seh ich aber kein Cancel-Lock. Das dürfte der Fehler sein.
Ja, natürlich nicht, da ich das nie gesetzt habe. Hätte ich
ja auch nicht vorausahnen können. Ich poste ja seit
Eweigkeiten so ganz problemlos.
pi
Roman Racine
Ach so, jetzt kapier ich's. Na, immerhin werden zukünftige Artikel ja dann
wieder korrekt gehandhabt, weil ja jetzt ein Cancel-Key eingefügt ist.
Ulrich F. Heidenreich
>Kathinka Wenz schrieb:
>> Trotz oder eigentlich wegen der vielen Missbrauchsmöglichkeiten ist mir
>> Usenet lieber als jedes Forum. Weil es eben völlig unzensiert ist.
>Dafür wichtig ist, daß Fremdcancel nicht - dauerhaft - möglich sind.
>Sonst ist Usenet sehr wohl schnell zensiert. :)
Irgendie sehe ich das geringfügig anders:
a) Wenn ich einerseits "unzensiertes" Usenet lesen möchte, dann habe
ich die Wahl, dazu auf einen Server zurückzugreifen, der keine Cancel
ausführt. Der liefert mir dann quasi "Usenet Raw", in dem es weder
Eigen- noch Fremdcancel gibt.
b) Andererseits fühle ich mich aber durch das Vorgehen von individual
ein wenig in meinem Recht beschnitten, eigene Artikel - mit dem für
mich vertretbaren Aufwand - canceln zu dürfen. Und ja, ich weiß, daß
der Artikel wegen a) nicht ganz aus der Welt ist, sähe es aber zur
Vermeidung von Mißverständnissen bei Tippfehlern (Das berühmte
vergessene "nicht" an der richtigen Stelle ist da so ein Kandidat)
äußerst ungern, wenn ich dort keine Korrekturen vornehmen könnte.
Supersedes zählt dabei nicht. Kaum ein Client wertet das aus.
CU!
Ulrich
Roman Racine
> Supersedes zählt dabei nicht. Kaum ein Client wertet das aus.
Das kapiere ich jetzt nicht, grundsätzlich ist das ja Sache des Servers,
Supersedes auszuwerten. Ausserdem ist Supersedes vom Cancel-Lock genauso
betroffen, wie Cancel selbst auch.
Lutz Frommberger
> In <f65s26$p45$1...@ourwg.mine.nu>, Wolfgang Becker wrote:
> Lutz Frommberger <Lutz.Fro...@gmx.de> wrote:
>> > Da darf man aber in der Doku erstmal ordentlich suchen. Im ersten Anlauf
>> > habe ich außer
>> Gibt es noch mehr?
>
Allerdings würde man es dort aber eher nicht suchen. Sollte man wohl
mal woanders hin schieben.
> u "ukd3" rs
Hm. dkauni2bit.net ist noch frei. Wär doch was.
Thomas Hühn
> b) Andererseits fühle ich mich aber durch das Vorgehen von individual
> ein wenig in meinem Recht beschnitten, eigene Artikel - mit dem für
> mich vertretbaren Aufwand - canceln zu dürfen. Und ja, ich weiß, daß
> der Artikel wegen a) nicht ganz aus der Welt ist, sähe es aber zur
> Vermeidung von Mißverständnissen bei Tippfehlern (Das berühmte
> vergessene "nicht" an der richtigen Stelle ist da so ein Kandidat)
> äußerst ungern, wenn ich dort keine Korrekturen vornehmen könnte.
>
> Supersedes zählt dabei nicht. Kaum ein Client wertet das aus.
Das macht auch der Server. Genau wie bei Cancels. Der Client muß da
nichts auswerten.
Thomas
Ulrich F. Heidenreich
Bist Du Dir da ganz sicher? Client holt Artikel A. Client holt Artikel B
der A supersedet. Wie soll da der Server dafür sorgen, daß A wieder aus
dem Client verschwindet? IMNSHO gehört dazu sehr wohl eine Aktion des
Clients.
CU!
Ulrich
Heiko Schlichting
>>"Ulrich F. Heidenreich" <nospam...@tremornet.de> writes:
>>>
>>> Supersedes zählt dabei nicht. Kaum ein Client wertet das aus.
>>
>>Das macht auch der Server. Genau wie bei Cancels. Der Client muß da
>>nichts auswerten.
>
> Bist Du Dir da ganz sicher?
Ja.
> Client holt Artikel A. Client holt Artikel B der A supersedet. Wie soll
> da der Server dafür sorgen, daß A wieder aus dem Client verschwindet?
Gar nicht. Genau wie bei Cancel-Nachrichten entfaltet sich die Wirkung nur
auf dem Server und hat nur dann den gewünschten Effekt, wenn die
Control-Nachricht eintrifft, bevor der Artikel vom Client geholt wird.
Ein "normaler" Client zeigt einen Artikel unmittelbar nach dem Abruf auf
dem Bildschirm an. Im Gehirn des Betrachters werden Cancel bzw. Supersedes
ohnehin durch Das-kannste-vergessen- und Ist-doch-alles-ganz-anders-
Controlmessages ersetzt, die nicht per NNTP transportiert werden müssen.
Heiko
Stefan Froehlich
> Im Gehirn des Betrachters werden Cancel bzw. Supersedes ohnehin durch
> Das-kannste-vergessen- und Ist-doch-alles-ganz-anders- Controlmessages
> ersetzt, die nicht per NNTP transportiert werden müssen.
haste-doch-schonmal-wo-gelesen-aber-wo, wie komme ich an das
notwendige Upgrade?
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Für grose Genießer - hauen mit Stefan!
(Sloganizer)
Nils Ketelsen
Aber nur bei Clients mit eigenem Spool, was zwar inzwischen häufig ist, aber
nicht die einzige Art.
Nils, mit Client der keine Artikel speichert (zumindest in meiner Konfig)
--
This message will self-destruct after the default expiration-time.
Ulrich F. Heidenreich
>Ulrich F. Heidenreich <nospam...@tremornet.de> wrote:
>> Thomas Hühn in <news:87abufj...@mid.thomas-huehn.de>:
>>>"Ulrich F. Heidenreich" <nospam...@tremornet.de> writes:
>>>>
>>>> Supersedes zählt dabei nicht. Kaum ein Client wertet das aus.
>>>
>>>Das macht auch der Server. Genau wie bei Cancels. Der Client muß da
>>>nichts auswerten.
>>
>> Bist Du Dir da ganz sicher?
>
>Ja.
>
>> Client holt Artikel A. Client holt Artikel B der A supersedet. Wie soll
>> da der Server dafür sorgen, daß A wieder aus dem Client verschwindet?
>
>Gar nicht.
Ebent.
Deswegen soll es ja Gerüchten zufolge Clients geben, die beim Eintreffen
eines Supersedes den Originalartikel lokal überschreiben. Gerade bei
FAQs, die in relativ großen Zeitabständen gesupersedet werden, ist es ja
eher die Regel denn die Ausnahme, daß die alte Version deutlich vor dem
Supersedes geholt werden kann.
Da diese Clients wohl recht spärlich gesät sind, halte ich Supersedes
für eine denkbar schlechte Möglichkeit, um mißverständliche Tippfehler
ausmerzen zu können. Und Canceln fällt ja jetzt wohl flach; außer ich
postete direkt über individual.
Gibt's eigentlich irgendeine Möglichkeit darum zu bitten, meine Artikel
nicht mehr via individual verbreitet zu sehen, weil es mit den mir zur
Verfügung stehenden Möglichkeiten nicht mehr machbar ist, ein Cancel
dorthin "hinterherschicken" zu können?
CU!
Ulrich
Roman Racine
> Deswegen soll es ja Gerüchten zufolge Clients geben, die beim Eintreffen
> eines Supersedes den Originalartikel lokal überschreiben. Gerade bei
> FAQs, die in relativ großen Zeitabständen gesupersedet werden, ist es ja
> eher die Regel denn die Ausnahme, daß die alte Version deutlich vor dem
> Supersedes geholt werden kann.
Nach einem erfolgreichen Supersedes ist der alte Artikel auf dem Server gar
nicht mehr verfügbar, Client hin oder her. Control-Messages richten sich
primär an Server, nicht an Clients.
> Da diese Clients wohl recht spärlich gesät sind, halte ich Supersedes
> für eine denkbar schlechte Möglichkeit, um mißverständliche Tippfehler
> ausmerzen zu können. Und Canceln fällt ja jetzt wohl flach; außer ich
> postete direkt über individual.
Supersedes ist vom Cancel-Lock-Mechanismus genauso betroffen wie Cancel oder
"Replaces". Canceln fällt nicht flach, wenn du selbst ein Cancel-Lock
einbaust. Oder aber den Betreiber deines Newsservers darum bittest, dies
serverseitig zu implementieren.
> Gibt's eigentlich irgendeine Möglichkeit darum zu bitten, meine Artikel
> nicht mehr via individual verbreitet zu sehen, weil es mit den mir zur
> Verfügung stehenden Möglichkeiten nicht mehr machbar ist, ein Cancel
> dorthin "hinterherschicken" zu können?
Ja, klar. Telefon, E-Mail, Brief, Fax. Am besten Telefon, vielleicht hat ja
jemand ein offenes Ohr für dich, wenn du wieder mal herumjammern willst.
Alexander Bartolich
> Heiko Schlichting in <news:5es2tgF...@mid.uni-berlin.de>:
>>Ulrich F. Heidenreich <nospam...@tremornet.de> wrote:
>>> Client holt Artikel A. Client holt Artikel B der A supersedet. Wie soll
>>> da der Server dafür sorgen, daß A wieder aus dem Client verschwindet?
>>
>>Gar nicht.
>
> Ebent.
>
> Deswegen soll es ja Gerüchten zufolge Clients geben, die beim Eintreffen
> eines Supersedes den Originalartikel lokal überschreiben.
Es gibt Clients mit lokalem Spool. Manche davon ignorieren Cancel bzw.
Supersede, manche führen sie aus.
In jedem Fall sind sie aber abhängig davon, dass sie die betreffenden
Cancel- bzw. Supersedes-Postings vom Server empfangen.
> Gerade bei FAQs, die in relativ großen Zeitabständen gesupersedet
> werden, ist es ja eher die Regel denn die Ausnahme, daß die alte
> Version deutlich vor dem Supersedes geholt werden kann.
Ja, und? Es ist ja der Sinn es eines Supersedes, ein altes Posting
mit einem neuen zu ersetzen.
> Da diese Clients wohl recht spärlich gesät sind,
Clients, die Cancel bzw. Supersedes im lokalen Newsspool ausführen?
> halte ich Supersedes für eine denkbar schlechte Möglichkeit, um
> mißverständliche Tippfehler ausmerzen zu können.
Ein Supersedes entspricht einem Cancel plus einem neuen Posting,
nur halt in einem Posting vereint.
> Und Canceln fällt ja jetzt wohl flach; außer ich postete direkt
> über individual.
Auch Supersedes sind durch Cancel-Lock bzw. Cancel-Key geschützt.
Wie gesagt entspricht ein Supersedes einfach einem Cancel plus einem
neuen Posting,
> Gibt's eigentlich irgendeine Möglichkeit darum zu bitten, meine Artikel
> nicht mehr via individual verbreitet zu sehen,
Theoretisch gibt es Path-Preloading.
Aber Cancel-Controls waren und sind immer nur unverbindliche Anfragen
ein Posting bereits vor dem natürlich Expire zu löschen. Es gab und
gibt keine Verpflichtung, Cancel auszuführen.
> weil es mit den mir zur Verfügung stehenden Möglichkeiten nicht mehr
> machbar ist, ein Cancel dorthin "hinterherschicken" zu können?
Path: news.albasani.net!feeder06.uucp-net.de!news.uucp.at!uucp.gnuu.de!enzian.dtdns.net!not-for-mail
UUCP considered harmful.
Wolfgang Becker
> Mehr Anläufe? Glaube nicht. Wahrscheinlich reichts, was in
> ~/.cancelsecret reinzuschreiben. Aber mir ist es eigentlich recht
> egal, ob in Berlin meine Cancels ankommen oder nicht.
Sieht so aus als reicht das. Danke. Gut, da ich eh fast nichts
cancle könnte es mir egal sein, aber wenn mein Reader das schon
kann, dann nutz ich es jetzt auch.
Tschüß,
Wolfgang
--
Wolfgang Becker *** eMail ua...@gmx.de *** http://uafr.freeshell.org/
Michael Hermes
[..]
>>> Aber tin ist ja eh kein Einsteiger-Newsreader.
>> Zum Glück hat mir das als ich Einsteiger war keiner gesagt hat.
> Wenn ich uafr richtig interpretiere und das genauso lang her ist
> wie un43 bei mir, dann wundert mich das nicht. Ich bin dennoch
> nicht mit tin eingestiegen.
un__? Auch Info?
Also bei mir damals als unjy stand in der Anleitung vom rz nur etwas über
tin. Nachdem ich den 1/2 Jahr benutzt hatte bin ich dann mal über xnews
gestolpert aber für den brauchte man ja ein x was nur auf den Rechnern
verfügbar war die dauernd belegt waren.
--
"Die armen Ostdeutschen. 40 Jahre lang wurde ihnen erzählt der Kapitalismus
sei zynisch und menschenverachtend. Und 40 Jahre lang haben sie geglaubt
das wäre eine Propagandalüge."
Hagen Rether
Ralph Angenendt
> Gibt's eigentlich irgendeine Möglichkeit darum zu bitten, meine Artikel
> nicht mehr via individual verbreitet zu sehen, weil es mit den mir zur
> Verfügung stehenden Möglichkeiten nicht mehr machbar ist, ein Cancel
> dorthin "hinterherschicken" zu können?
Distribution: irrelevant
Ralph
--
Der Osten ist das neue Bochum.
Nicht schreiben können: http://lestighaniker.de/
Toni Grass
[....]
>Da diese Clients wohl recht spärlich gesät sind, halte ich Supersedes
>für eine denkbar schlechte Möglichkeit, um mißverständliche Tippfehler
>ausmerzen zu können. Und Canceln fällt ja jetzt wohl flach; außer ich
>postete direkt über individual.
Ich habe am WoE ein Posting nach at.test über einen anderen Server
gecancelled und dann bei Individual nachgesehen, das war auch dort weg.
Denke, das war kein Zufall.
Toni
Manuel Reimer
> Gleichzeitig haben wir die Verarbeitung von "Cancel Locks" (aka
> "canlock") aktiviert. Nutzer, die im Cancel bzw. Supersedes einen
> passenden Cancel-Key mitschicken, können also weiterhin ihre Artikel
> auf unseren Servern löschen oder überschreiben.
Ich bin zwar schon länger nicht mehr bei Individual, würde mich aber
doch dafür interessieren, wie dieses Verfahren genau abläuft...
Das Posting selber muss einen Key haben (Cancel-Lock) und das Posting,
welches den Cancel auslösen soll, braucht auch einen passenden Key
(Cancel-Key).
Nehmen wir an, ein Posting wird über Individual eingestellt und erhält
so einen Cancel-Lock. Wie erzeuge ich aus diesem Key einen passenden
Cancel-Key.
Kann der Cancel-Lock, den ich über den Clienten selber erzeuge, denn
immer gleich sein, sodass ich auch immer den gleichen Cancel-Key nutzen
kann?
Wie erzeuge ich die Keys ggf. manuell?
CU
Manuel
--
Privatsphäre bald Geschichte? Vorratsdatenspeicherung, Bundestrojaner, ...
Informieren, bevor es zu spät ist! Es sind auch deine Rechte!
www.vorratsdatenspeicherung.de www.der-bundestrojaner.de
www.againsttcpa.com www.privatkopie.net www.foebud.org
Alexander Skwar
> Nehmen wir an, ein Posting wird über Individual eingestellt und erhält
> so einen Cancel-Lock. Wie erzeuge ich aus diesem Key einen passenden
> Cancel-Key.
Du? Gar nicht. Bei Cancel-Lock wird etwas verschlüsseltes mitgesendet.
Dieses verschlüsselte kann aus der Message-ID und einem geheimen
Teil bestehen. Diesen geheimen Teil wird Dir individual.de sicherlich
nicht mitteilen.
Allerdings kannst Du selber einen Cancel-Lock Header hinzufügen. Individual
wird dann noch einen zusätzlichen Schlüssel anfügen, was Dich aber nicht
stören braucht.
> Kann der Cancel-Lock, den ich über den Clienten selber erzeuge, denn
> immer gleich sein, sodass ich auch immer den gleichen Cancel-Key nutzen
> kann?
So wie ich den Draft verstehe: Ja.
> Wie erzeuge ich die Keys ggf. manuell?
Siehe: http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01#section-4
Alexander Skwar
Roman Racine
> NetNews-Team Individual.DE wrote:
>> Gleichzeitig haben wir die Verarbeitung von "Cancel Locks" (aka
>> "canlock") aktiviert. Nutzer, die im Cancel bzw. Supersedes einen
>> passenden Cancel-Key mitschicken, können also weiterhin ihre Artikel
>> auf unseren Servern löschen oder überschreiben.
>
> Ich bin zwar schon länger nicht mehr bei Individual, würde mich aber
> doch dafür interessieren, wie dieses Verfahren genau abläuft...
>
> Das Posting selber muss einen Key haben (Cancel-Lock) und das Posting,
> welches den Cancel auslösen soll, braucht auch einen passenden Key
> (Cancel-Key).
>
> Nehmen wir an, ein Posting wird über Individual eingestellt und erhält
> so einen Cancel-Lock. Wie erzeuge ich aus diesem Key einen passenden
> Cancel-Key.
Das kannst du nicht, sofern Individual ein sicheres Verfahren zur Erzeugung
von Keys einsetzt. Das ist der Witz der Sache. Nur der, der das Cancel-Lock
gesetzt hat, kann den Key angeben, somit werden unerlaubte Cancel
unterbunden.
Du hast die Möglichkeit, selbst ein Lock zu setzen, in diesem Fall setzt
Individual einfach noch ein zusätzliches, dann kannst du auch über einen
anderen Server canceln, denn solange der von dir angegebene Key zu einem
der Locks passt, kannst du canceln.
> Kann der Cancel-Lock, den ich über den Clienten selber erzeuge, denn
> immer gleich sein, sodass ich auch immer den gleichen Cancel-Key nutzen
> kann?
Das kann er, allerdings ist das gar keine gute Idee. Wenn das Lock immer das
gleiche ist, kann jemand, der deinen Key einmal gesehen hat, dann alle
deine Postings canceln. Um ohne grossen Aufwand Keys zu erzeugen, kannst du
eine kryptografisch sichere Einwegfunktion verwenden. Wenn du
SHA1(MID||Geheimer String) verwendest, brauchst du nur den geheimen String
irgendwo sicher aufzubewahren, den Key für ein bestimmtes Posting kannst du
dann mit der Message-ID erzeugen. Da SHA1 nach heutigen Erkenntnissen eine
sichere Einwegfunktion ist, kann niemand aus von dir bekannt gegebenen Keys
Keys für andere Locks berechnen. Der Geheime String muss allerdings lang
genug sein, um Brute Force Attacken zu verhindern.
> Wie erzeuge ich die Keys ggf. manuell?
Mit Perl z.B. so:
#!/usr/bin/perl -w
use MIME::Base64;
use Digest::SHA1;
use strict;
use warnings;
my $GEHEIMER_WERT = 'abcdefghijklmnop';
sub generate_key($);
sub generate_lock($);
my $key = generate_key($ARGV[0]);
print 'Key: ', $key,"\n";
print 'Lock: ', generate_lock($key),"\n";
sub generate_key($) {
my $mid = shift;
return MIME::Base64::encode_base64(Digest::SHA1::sha1($mid .
$GEHEIMER_WERT),'');
}
sub generate_lock($) {
my $key = shift;
return MIME::Base64::encode_base64(Digest::SHA1::sha1($key),'');
}
__DATA__
./generate_key.pl '<te...@blabla.example>'
Key: dd5+Z0C1EmRabDTGchG40TW4GrA=
Lock: darbxZDIgpJNOTLPHpAgwmluzpc=
Sascha Grage
> Du hast die Möglichkeit, selbst ein Lock zu setzen, in diesem Fall setzt
> Individual einfach noch ein zusätzliches, dann kannst du auch über einen
> anderen Server canceln, denn solange der von dir angegebene Key zu einem
> der Locks passt, kannst du canceln.
>
>> Kann der Cancel-Lock, den ich über den Clienten selber erzeuge, denn
>> immer gleich sein, sodass ich auch immer den gleichen Cancel-Key nutzen
>> kann?
>
> Das kann er, allerdings ist das gar keine gute Idee. Wenn das Lock immer das
> gleiche ist, kann jemand, der deinen Key einmal gesehen hat, dann alle
> deine Postings canceln. Um ohne grossen Aufwand Keys zu erzeugen, kannst du
> eine kryptografisch sichere Einwegfunktion verwenden. Wenn du
>
> SHA1(MID||Geheimer String) verwendest, brauchst du nur den geheimen String
> irgendwo sicher aufzubewahren, den Key für ein bestimmtes Posting kannst du
> dann mit der Message-ID erzeugen.
Wenn ich dann über einen anderen Server canceln, woher soll Individual dann
meinen geheimen String wissen?
Gruß,
Sascha
--
Beer is proof that God loves us and wants us to be happy...
(c)
np: --
Roman Racine
Den geheimen String muss niemand wissen ausser du, den gibst du natürlich
nirgendwo an. Prinzipiell funktioniert das Verfahren so, dass man eine
kryptografisch sichere Einwegfunktion wie SHA1 verwendet:
1. Hat man einen Wert x, ist y = SHA1(x) leicht zu berechnen.
2. Hat man dagegen den Wert y und kennt x nicht, kann man mit heute zur
Verfügung stehenden Mitteln x nicht errechnen.
Konzeptionell funktioniert das so, dass das Cancel-Lock
SHA1(SHA1(MID||Geheimer String)) ist. Diesen Wert gibst du öffentlich
bekannt. Der Cancel-Key ist dagegen SHA1(MID||Geheimer String).
Da SHA1 als kryptografisch sichere Funktion gilt, kann niemand aus dem
Cancel-Lock den Cancel-Key berechnen, der den geheimen String nicht kennt,
dies wegen Bedingung 2 von oben. (Brute Force, d.h. durchprobieren
möglicher Werte für den geheimen String ausgenommen, deshalb muss der
geheime String lange genug sein.)
Wenn du den Cancel-Key später beim Canceln angibst, kann dagegen jeder
leicht überprüfen, ob der Cancel-Key zum Lock passt, weil er einfach SHA1
davon berechnen muss, dies wegen Bedingung 1 von oben.
Vom Cancel-Key kann man dagegen nicht auf deinen geheimen String schliessen,
dies wieder um wegen 2 oben.
Dein geheimer String dient für dich nur dazu, Cancel-Keys und Locks zu
erzeugen. Niemand ausser du muss ihn wissen.
Sascha Grage
> Konzeptionell funktioniert das so, dass das Cancel-Lock
> SHA1(SHA1(MID||Geheimer String)) ist. Diesen Wert gibst du öffentlich
> bekannt. Der Cancel-Key ist dagegen SHA1(MID||Geheimer String).
Jetzt hab auch ich's kappiert ;-) Danke
Oliver Cromm
> Heiko Schlichting in <news:5es2tgF...@mid.uni-berlin.de>:
>
>>Ulrich F. Heidenreich <nospam...@tremornet.de> wrote:
>>
>>> Client holt Artikel A. Client holt Artikel B der A supersedet. Wie soll
>>> da der Server dafür sorgen, daß A wieder aus dem Client verschwindet?
>>
>>Gar nicht.
>
> Ebent.
>
> Deswegen soll es ja Gerüchten zufolge Clients geben, die beim Eintreffen
> eines Supersedes den Originalartikel lokal überschreiben.
Wenn sie in der richtigen Reihenfolge eintreffen, macht das Dialog.
> Gerade bei
> FAQs, die in relativ großen Zeitabständen gesupersedet werden, ist es ja
> eher die Regel denn die Ausnahme, daß die alte Version deutlich vor dem
> Supersedes geholt werden kann.
>
> Da diese Clients wohl recht spärlich gesät sind, halte ich Supersedes
> für eine denkbar schlechte Möglichkeit, um mißverständliche Tippfehler
> ausmerzen zu können. Und Canceln fällt ja jetzt wohl flach; außer ich
> postete direkt über individual.
Bei Canceln passiert überhaupt nichts im Client, wenn ich das Original
einmal habe. Auch der Hamster kann doch Cancel gar nicht ausführen, wenn
er nicht gefeedet wird, oder? Insofern hat ein Supersedes bessere
Chancen, von mir bemerkt zu werden, als ein Cancel. Ist das bei Dir
anders? Warum?
--
Bill Gates working as a waiter:
- Waiter, there's a fly in my soup
- Try again, maybe it won't be there this time
Oliver Cromm
> Ulrich F. Heidenreich wrote:
>
>> Deswegen soll es ja Gerüchten zufolge Clients geben, die beim Eintreffen
>> eines Supersedes den Originalartikel lokal überschreiben. Gerade bei
>> FAQs, die in relativ großen Zeitabständen gesupersedet werden, ist es ja
>> eher die Regel denn die Ausnahme, daß die alte Version deutlich vor dem
>> Supersedes geholt werden kann.
>
> Nach einem erfolgreichen Supersedes ist der alte Artikel auf dem Server gar
> nicht mehr verfügbar, Client hin oder her. Control-Messages richten sich
> primär an Server, nicht an Clients.
Nach meiner Erfahrung ist das meist nicht der Fall, sie wird, genau wie
bei Cancels, nur aus dem Overview entfernt. Habe ich die Message-Id,
komme ich in der Regel ans Original.
--
If the aeroplane industry had advanced at the same rate as the computer
industry, today's planes could circumnavigate the world in ten seconds,
be two inches long, and crash twice a day.
Peter Moylan in alt.usage.english
Oliver Cromm
> Roman Racine meinte:
>
>> Konzeptionell funktioniert das so, dass das Cancel-Lock
>> SHA1(SHA1(MID||Geheimer String)) ist. Diesen Wert gibst du öffentlich
>> bekannt. Der Cancel-Key ist dagegen SHA1(MID||Geheimer String).
>
> Jetzt hab auch ich's kappiert ;-) Danke
In einem der verlinkten Texte war es so erklärt, der Mechanismus
funktioniere mit einem "shared secret". Daher habe ich mich dasselbe
gefragt. Dank auch von hier.
--
The Internet? Is that thing still around? - Homer Simpson
Jörg Tewes
> Ulrich F. Heidenreich wrote:
>> Deswegen soll es ja Gerüchten zufolge Clients geben, die beim
>> Eintreffen eines Supersedes den Originalartikel lokal
>> überschreiben. Gerade bei FAQs, die in relativ großen
>> Zeitabständen gesupersedet werden, ist es ja eher die Regel denn
>> die Ausnahme, daß die alte Version deutlich vor dem Supersedes
>> geholt werden kann.
> Nach einem erfolgreichen Supersedes ist der alte Artikel auf dem
> Server gar nicht mehr verfügbar, Client hin oder her.
Du kennst Clients nur Artikel holen und danach wieder Offline gehen?
Wenn der Client den nämlich Artikel, vor dem erfolgreichen Supersedes
vom Server holt, ist er sehr wohl noch vorhanden. Wenn der Client
jetzt das zweite Mal online geht, und den Supersede abholt, dann hat
man beide Artikel lokal vorliegen.
> Control-Messages richten sich primär an Server, nicht an Clients.
Nein aber es gibt auch Clients die Cancel und Supersedes lokal
verarbeiten.
Und Tschüss Jörg
--
"You got a plan?"
"Let's try not to get killed."
"Brilliant."
(Ivanova and Sheridan, "The Long Dark")
Ulrich F. Heidenreich
> Insofern hat ein Supersedes bessere
>Chancen, von mir bemerkt zu werden, als ein Cancel. Ist das bei Dir
>anders? Warum?
Weil ich kein Dialog nutze. Meien Denkrichtung war einfach jene, daß
ich mangels Cancelausführung nur noch per Supersedes zum Verschwinden
der unerwünschten Fassung auf individual sorgen kann. Da dies kaum ein
Client umsetzt, halte ich das für suboptimal.
CU!
Ulrich
Thomas Hühn
> Weil ich kein Dialog nutze. Meien Denkrichtung war einfach jene, daß
> ich mangels Cancelausführung nur noch per Supersedes zum Verschwinden
> der unerwünschten Fassung auf individual sorgen kann. Da dies kaum ein
> Client umsetzt, halte ich das für suboptimal.
Cancels und Supersedes werden aber gleichbehandelt, daher kannst du das
halt ohnehin nicht "besser" erreichen als durch Cancels.
Thomas
Ulrich F. Heidenreich
Ulrich F. Heidenreich
>Nein aber es gibt auch Clients die Cancel und Supersedes lokal
>verarbeiten.
Und genau letztere wären nötig, damit Individuals' Bitte, statt Cancel
nun Supersedes zu nutzen, praktische Wirkung zeigten. Da die recht
selten gesät sind, halte ich das für eine recht suboptimale Methode.
Nochmal kurz zum Thema Cancel-Lock; leider beziehen sich die wenigen
Quellen, die ich finde, auf Gnus und Konsorten. Was wäre genau zu tun?
Bis dato spekuliere ich auf
a) Jeden meiner Artikel mit einem "Cancel-Lock:"-Header versehen,
der wohl einen Hashwert aus meinem Geheimwort und der Message-ID
beinhaltet.
b) Wollte ich diesen Artikel erfolgreich von individuial entfernt
sehen, müßte die Cancel-Nachricht einen "Cancel-Key:"-Header
enthalten, der gleichermaßen(?) gebildet wurde.
Gibt's Utilities, die mir unter DOS/Windoof dieses "sha1" berechnen?
CU!
Ulrich
P.S.: Ich laß die Fragen zunächst mal in dcpu stehen. Wenn's in
eine spezifische(re) Richtung geht, bitte dann geeignet fuppen.
Rainer Georg Blankenagel
<nospam...@tremornet.de>>:
Message-ID: <2007-06-28...@fu-berlin.de>:
| Verzichten Sie auf Cancels und verschicken Sie stattdessen
| Supersedes. Dadurch erscheint auf Servern, die keine
| Cancels und Supersedes ausführen, ein zweiter Artikel in
| sichtbarer Nähe zum ersten, und die Leser können erkennen,
| dass es zu Ihrem Artikel eine zweite, neuere Fassung gibt.
HTH,
Rainer
Ulrich F. Heidenreich
>HTH,
Solange da kaum ein Client wirkungsvoll darauf reagiert, eher nicht.
Trozudem Danke für die Wiederholung.
CU!
Ulrich
Ralph Angenendt
Wieso? Es stehen beide Artikel da.
Roman Racine
Es wurde dir bereits x-fach erklärt, dass Supersedes genau den gleichen
Cancel-Lock-Mechanismus benützt wie Cancel ... Gehen deine Cancels nicht
durch, gehen auch deine Supersedes-Nachrichten nicht durch.
Gruss
Roman°
Rainer Georg Blankenagel
<nospam...@tremornet.de>>:
> Rainer Georg Blankenagel in <news:wffd1j1onj82.1ewou48cbokpd$.d...@40tude.net>:
Ich habe eher den Eindruck, daß Du die Passage nicht richtig verstehst.
Rainer
Toni Grass
>Rainer Georg Blankenagel in <news:wffd1j1onj82.1ewou48cbokpd$.d...@40tude.net>:
>>HTH,
>Solange da kaum ein Client wirkungsvoll darauf reagiert, eher nicht.
Du meinst, den älteren Artikel automagisch im Client unterdrücken?
Toni
--
Ein Patch sie zu knechten, Resourcen zu finden
Ins Dunkel zu treiben und ewig zu binden
Nils Ketelsen
>> Control-Messages richten sich primär an Server, nicht an Clients.
> Nein aber es gibt auch Clients die Cancel und Supersedes lokal
> verarbeiten.
Dazu muß man dann aber in den gängigen newsservern die Gruppe "control" oder
"control.cancel" abbonieren (nicht bei Supersedes, wohl aber bei Cancels),
was bei einem Newsserver mit vielen Hierarchien schon recht sportliche
Artikelzahlen bedeutet.
Nils
--
> What's the title for the head of the Greek Orthodox church?
God
[Rowan Mayfair <row...@innocent.com>]
Nils Ketelsen
>> Weil ich kein Dialog nutze. Meien Denkrichtung war einfach jene, daß
>> ich mangels Cancelausführung nur noch per Supersedes zum Verschwinden
>> der unerwünschten Fassung auf individual sorgen kann. Da dies kaum ein
>> Client umsetzt, halte ich das für suboptimal.
> Cancels und Supersedes werden aber gleichbehandelt, daher kannst du das
> halt ohnehin nicht "besser" erreichen als durch Cancels.
Supersedes kommen i.A. immerhin in allen Clients an, Cancels eher nicht. Das
gibt dem Client zumindest schonmal die Chance sie auszuwerten. Nicht das ich
einen Client kennen würde der es tut, aber das ist ein anderes Problem.
Man könnte natürlich mit "Also-Control: " Header canceln, dann kommen sie
an, aber das will man ja bei einem Cancel normalerweise gerade nicht.
Nils
--
Will trade links for food.
[geklaut bei
www.userfriendly.org]
Oliver Cromm
Meine Frage war eher, ob bei den Canceln was bei Dir anders ist. Die
setzt doch *erst recht* kein Client um (Nils hat beschrieben, warum). So
gesehen war Supersedes eh schon immer deutlicher als Cancel, Dialog oder
nicht, Individual oder nicht.
--
Java is kind of like kindergarten. There are lots of rules you have to
remember. If you don't follow them, the compiler makes you sit in the
corner until you do. - Don Raab
Hans-Juergen Taenzer
> Jörg Tewes <jogi...@gmx.net> wrote:
>>> Control-Messages richten sich primär an Server, nicht an Clients.
>> Nein aber es gibt auch Clients die Cancel und Supersedes lokal
>> verarbeiten.
> Dazu muß man dann aber in den gängigen newsservern die Gruppe
> "control" oder "control.cancel" abbonieren (nicht bei Supersedes,
> wohl aber bei Cancels),
Nein, warum? Mein Reader zB. kann mit beidem umgehen.
Hans-Jürgen
Sascha Grage
>> Dazu muß man dann aber in den gängigen newsservern die Gruppe
>> "control" oder "control.cancel" abbonieren (nicht bei Supersedes,
>> wohl aber bei Cancels),
>
> Nein, warum? Mein Reader zB. kann mit beidem umgehen.
Wie kommt der an die Control-Nachrichten?
Ulrich F. Heidenreich
>· Well, Ulrich F. Heidenreich <nospam...@tremornet.de> wrote:
>> Rainer Georg Blankenagel in <news:wffd1j1onj82.1ewou48cbokpd$.d...@40tude.net>:
>>
>>>HTH,
>>
>> Solange da kaum ein Client wirkungsvoll darauf reagiert, eher nicht.
>> Trozudem Danke für die Wiederholung.
>
>Wieso? Es stehen beide Artikel da.
Beim Cancel und korrigiertem Repost (implizit auf einem Server, der
Beides unterbindet) auch. Demzufolge mag ich keinerlei Vorteil in der
Empfehlung sehen, nun zu superseden statt zu canceln. Außer, es gäbe
eine signifikanten Anteil an Clients, die einen Supersedes auswerten.
Aber genau den gibt's ja offensichtlich nicht.
CU!
Ulrich
Ulrich F. Heidenreich
>Meine Frage war eher, ob bei den Canceln was bei Dir anders ist.
Jetzt ja, machdem sie wirkunglsos sind, sobald der Artikel individual
erreicht hat. Als Alternative wird ja Supersedes vorgeschlagen. Wenn
und da der aber in kaum einem Client ausgewertet wird, sehe ich das
eher als suboptimalen Ersatz für einen "echten Cancel"[TM] an.
CU!
Ulrich
Nils Ketelsen
>>>> Control-Messages richten sich primär an Server, nicht an Clients.
>>> Nein aber es gibt auch Clients die Cancel und Supersedes lokal
>>> verarbeiten.
>> Dazu muß man dann aber in den gängigen newsservern die Gruppe
>> "control" oder "control.cancel" abbonieren (nicht bei Supersedes,
>> wohl aber bei Cancels),
> Nein, warum? Mein Reader zB. kann mit beidem umgehen.
Wie findet der denn die Cancels die er braucht?
Nils
--
Nie wieder darf von diesem Land Gewalt ausgehen.
Wir muessen Flagge zeigen duerfen nicht bei Seite stehen.
Rein humanitaer natuerlich und ganz ohne Blutvergiessen.
Kampfeinsaetze sind jetzt nicht mehr so ganz auszuschliessen.
Nils Ketelsen
> Oliver Cromm in <news:1962w54n...@ocromm.my-fqdn.de>:
>>Meine Frage war eher, ob bei den Canceln was bei Dir anders ist.
> Jetzt ja, machdem sie wirkunglsos sind, sobald der Artikel individual
> erreicht hat. Als Alternative wird ja Supersedes vorgeschlagen. Wenn
Nur dort.
> und da der aber in kaum einem Client ausgewertet wird, sehe ich das
> eher als suboptimalen Ersatz für einen "echten Cancel"[TM] an.
Weil diese auch von kaum einem Client ausgewertet werden? Ja, mehr noch, sie
die meisten Clients nichtmal erreichen?
Beides funktioniert ja weiter wunderbar wie vorher, nur halt bei der
FU-Berlin nicht. Mir ist unklar, warum das irgendeine Wirkung hat. Wie schon
vorher gibt es ein Paar Newsserver, die normale Cancels/Supersedes auswerten
und einige die es nicht tun. Nur weil die FU das Ufer wechselt (in dieser
Sache) ändert sich doch nichts signifikantes an der Sache.
Nils
--
You're not drunk if you can lie on the floor without holding on.
[Dean Martin]