Re: Cancel Richtlininen fuer at.* (2. Entwurf)

[lendl·cosy.sbg.ac.at (Otmar Lendl)]

[ Ich war vier Tage offline, daher die spaete Antwort. ]

Johannes DEMEL <demel·tron.kom.tuwien.ac.at> wrote:
>Otmar Lendl (lendl·cosy.sbg.ac.at) wrote:
>: Johannes DEMEL <demel·tron.kom.tuwien.ac.at> wrote:
>: >Otmar Lendl (lendl·cosy.sbg.ac.at) wrote:
>: >: Johannes DEMEL <demel·tron.kom.tuwien.ac.at> wrote:
>: >: 
>: >: Wollt ihr at.tuwien.* ausnehmen ? Gut ist *MIR* voellig egal. 
>: >: Muss wirklich erst at.tuwien.edvz.neuigkeiten zugemuellt werden,
>: >: bevor euch die Augen aufgehen ?
>
>und das soll auch bei moderierten Newsgruppen gehen?

Soll ich's demonstrieren ?    ;-)/2

Ernsthafte Spammer includieren immer einen Approved: header in
ihren Nachrichten, womit diese auch in moderierten Gruppen 
weitergegeben werden. Daher wurden news.announce.important oder
wie schon angesprochen comp.os.linux.announce nicht verschont.

Es ist zwar ein netter hack (wenn's denn beabsichtigt ist), dass
die Gruppe nur auf news.tuwien als moderiert gefuehrt wird,
aber gegen hard-core spams hilft das nichts.

[...]

>Also bei uns gibt es aufgrund bereits stattgefundener Diskussion 
>diese Entscheidungsfreiheit fuer den Newsadmin oder mich sicher nicht !
>Ich kann mir auch nicht vorstellen, dass bei einem kommerziellen Anbieter
>es z.B. dem Newsadmin ueberlassen wird, welche Files von News oder
>Kunden geloescht werden oder welche Newsgruppen verfuegbar sind.
>Es wuerde wohl auch jeder Kunde eines Rechnerservices (egal ob
>Kommerziell oder Universitaer) aufschreien, wenn der Systemadminstrator
>seine Root-Berechtigung dazu verwendet, Mails  oder Files zu loeschen.

Bei kommerziellen Anbietern ist es ueblich, dass sie helfen, den
Schaden Ihrer spammenden Kunden mittels Cancels wiedergutzumachen.

Aber unterscheiden wir bitte zwei Faelle:

1. Ein Fremder spammt. Irgendwo aus .com oder .edu. 

	Das Loeschen dieser (redundanten) Nachrichten per Cancel tangiert
	User der TU nur insofern, als sie diese Nachrichten nicht in all
	den Gruppen, die der Absender vorgesehen hat, lesen koennen.

	Keine Files, die irgendwelchen TU-Users gehoeren, werden tangiert.

2. Ein TU-User spammt.

	Unter http://nic.tuwien.ac.at/nic/policy10.htm finde ich

	2.2 Eine unmäÁige Verwendung fßr private Zwecke oder 
	    persÐnliche Geschäfte ist unzulässig.

	und

	2.7 Eine Verwendung, die eine grobe Belästigung oder Verängstigung 
		anderer Benßtzer bewirkt (FG 1993, â16(2) 2), ist unzulässig. 

	was meiner Interpretation nach spammen "unzulaessig" macht.
	Ab wann etwas eine "unmäÁige Verwendung" bzw. "grobe Belästigung" 
	ist, darum ging es bei der Diskussion ueber die Cancel-Kriterien.

	Die beiden obigen Paragraphen erklaeren genau, warum Spam im 
	Usenet nicht toleriert wird.

	Nehmen wir mal an, wir koennen uns auf eine klare Regelung einigen,
	wann 2.2 oder 2.7 bei Spams zutreffen. Was dann ? Der Spam 
	widerspricht dann den TUNET Benßtzungsregelungen, hat also
	kein Recht, weiterhin am TU Newsserver gespeichert zu werden.
	Analog koennte man sonst auch sagen, dass Grafitti nicht uebermalt
	werden darf. Oder (um ein klassisches Beispiel zu zitieren) dass 
	das EDVZ Kinderpornos auf Webseiten von TU-Usern nicht entfernen
	darf.

	Also bleibt als zu klaerende Frage, nach welchen Kriterien
	ein Spam eindeutig als solcher, und den TU-Richtlinien widersprechend
	eingestuft werden kann. Und um hier einen Konsens zu finden,
	fuehren wir diese Diskussion.

[...]

>
>: >	at.network.udnwien
>: >	at.network.aconet
>: 
>: Na schoen. <= 7. So wie ich den Entwurf gelesen habe, liegt die Schranke
>: bei 10, crossposting vorrausgesetzt.
>Also ich habe darin gelesen, dass einmal die Anzahl der Artikeln mit
>3 multipliziert wird (ich verstehe nicht warum aber was solls).
>Und dann ist obige Rechnung offensichtlich falsch.

So wie ich den Vorschlag gelesen habe, geht die Rechnung so:

	* Jeder Artikel bekommt 3 Punkte fuer die erste Gruppe, in der
	  er erscheint. Jede weitere Gruppe im Newsgroups: header
	  gibt einen weiteren Punkt.
	
	* Wird derselbe Artikel mehrmals gepostet, so addieren sich
	  die Punkte. 

	* Wird so die Schranke erreicht, darf gecancelt werden.

Kann der Autor das bitte verifizieren (bzw. klarer formulieren) ?

Also komm ich bei einem auf 7 Gruppen gecrosspostetem Announcement
auf 3+6=9 Punkte, also unter der vorgeschlagenen Schranke.

Wird die Ankuendigung aber einzelnd gepostet, so waere die Rechnung
3*7 = 21, also ueber der Schranke. 

Das ist ja der Sinn an diesen Formeln, dass Crossposting besser 
(ressourcen + belaestigungsmaessig) sind, als Multiposts.

>Ausserdem haengt die ganze Formel essentiell von der Definition
>von "im wesentlichen gleich" ab, die offensichtlich voellig offen ist.

Dazu gibt es Praezedenzfaelle. Ist man naemlich ganz starr und verlangt
"identisch", so wuerden simple "mail-merge" Tricks ausreichen,
den Mechanismus zu umgehen. Das gleiche passiert doch auch mit
Postwurfsendungen, die auch oft personalisierte Anreden enthalten.
Das aendert aber nichts daran, dass es Massensendungen bleiben.

>: In der Diskussion trat die Frage auf, ob at.blackbox.* und
>: at.fido.* in diese Regelung mitaufgenommen werden sollen. Niemand
>: hat an dieser Stelle angenommen, dass uni-hierarchien was gegen
>: Aufraeumaktionen haben.
>ich verstehe diesen Satz nicht.

Okay, anders formuliert:

Es gibt mehrere Subhierarchien unter at.* die ihre eigenen Regeln haben.
So etwa wurde ueberlegt, ob B*B und fido mitmachen wollen. An dieser
Stelle hatte niemand damit spekuliert, dass eine akademische 
Subhierarchie nicht an einer Spam-Cancel-Vereinbarung teilnehmen will.

>: Konstruktive Kritik und Aenderungsvorschlaege, wie sie von vielen Seiten
>: gekommen sind, versuche ich immer willkommen zu heissen. Aber ob man
>
>Da bei uns a priori die Regel gilt, dass fremde Sachen nicht geloescht
>werden duerfen, kann ich mir eigentlich keinen damit konformen 
>Aenderungsvorschlag vorstellen, der Ihnen gefallen wuerde.
>Ich habe hier praktisch keinen Handlungsspielraum!

Ich kann diesen Ansatz verstehen. Nach diesem handeln auch mehrere
groessere Sites (AFAIK demon, aol, ... ). Nur: Damit diese Haltung
konsequent ist, duerfen auch die Spam-cancels in den Grossen 
Usenet-Hierarchien nicht angenommen werden. Das ist technisch
relativ einfach machbar. Wie gesagt, die Patches dafuer, bzw. die
noetigen Einstellungen sind frei erhaeltlich.

Was ich nicht verstehe, ist zu sagen "wir toleriern Spam-cancels in
comp.* , aber verweigern sie aus prizipiellen Gruenden in at.*"

>
>Nur einige ganz prinzipielle konstruktive Vorschlaege einer solchen
>Festlegung:
>
>1. es fehlt eine konkrete Darstellung der Motivation des ganzen.

Ja. Das fehlt.

Meine Formulierung dazu waere etwa:

	"Undifferenziertes Posten einer Nachricht in viele Newsgroups
	widerspricht den Konventionen des Usenets, da es

		1. Ressourcen vergeudet 
		2. die Leser durch Wiederholungen irritiert
		3. die Einteilung in Gruppen nach Themen ignoriert.
	
	Damit das Usenet nicht in Spam (und Antworten darauf) ertrinkt, 
	werden diese Nachrichten zum Canceln freigegeben."


>2. Es fehlt eine klare Zielvorgabe. Sonst kann man naemlich nicht einmal
>   feststellen, ob die Regelung erfolgt hatte. Mir ist z.B. vollkommen 
>   unklar, ob das ganze eigentlich gegen Posting von at-rechnern in
>   at-gruppen oder von internationalen Rechnern in at-gruppen geht.
>   (die Massnahmen waeren da offensichtlich ganz anders!).
>   Und jetzt nicht sagen, das ist ja alles in der Diskussion gesagt
>   worden. Der Draft sollte wohl eine Zusammenfassung der Diskussion
>   sein ist daher genau das Resumee darueber enthalten.

So einfach es waere, nach Herkunft des Spams zu differenzieren,
so sehr widerspricht das IMHO dem Geist des Usenets. Weiters
ist das nicht immer so einfach, da es Oesterreichische Hosts unter
COM, ORG und NET gibt. 

>3. Am Anfang der Diskussion wurde die Frage diskutiert, ob ein
>   gemeinsames Programm geschrieben werden sollte, das dann jeder selber
>   (mit eigenen Parametern) verwendet, oder alles nur an einer Stelle
>   mit gemeinsamen Paramtern gemacht werden soll. Es wurden dann irgendwelche
>   fuer mich ziemlich unverstaendliche Argumente gebracht, dass nur 
>   die zentrale Loesung sinnvoll sei. 

Ich seh' das so: Da man das ganze nicht voll-automatisieren kann,
braucht es eine menschliche Intervention, und die Ressourcen dafuer
sind nicht ueberall vorhanden. Daher ist eine voellig dezentrale
*Loesung* nicht praktikabel.

>   Ich kann nur Sagen dass aus meiner Sicht die 'dezentrale Variante'
>   mit der lokalen Festlegung der 'politischen' Parametern das
>   richtige ist.

Das entspricht in etwa dem NoCeM Konzept. Ich hab's hier noch nie 
implementiert, aber damit sind sehr differenzierte policies moeglich.
Genaueres dazu gibt es unter http://www.cm.org/ nachzulesen.

otmar
-- 
/ Otmar Lendl (lendl·cosy.sbg.ac.at) # http://www.cosy.sbg.ac.at/~lendl/  \  
\ Killfiles generate SEP fields. Beware: the CE-Norm does not cover them. /