Ergänzende Anmerkungen

RfCs Gestaltung Plonk und Killfile Troll Signaturen

Zum tieferen Verständnis der Richtlinien noch einige Kommentare, die den anderen Text zu stark aufblähen würden.

RfC

RfC-Archive finden sich z.B. hier: Uni-Paderborn, Uni-Köln, TU-Berlin. Die für Usenet wichtigsten RfCs sind RfC822, RfC850 und RfC1036. Eine Zusammenfassung der Netiquette gibt es in RfC1855.

Einige Dinge, die von RfCs behandelt werden, sollen hier aufgezählt werden:

Autor: Der Autor einer Nachricht muß nach RfC1036 2.1.1 durch die Kombination Name + erreichbare und dem Autor zugeordnete E-Mail-Adresse im 'From:'-Header erkennbar sein. Dabei ist insbesondere die Absenderadresse zwingend vorausgesetzt. Falls der technische Absender ein anderer ist, so kann und sollte dessen Name + Adresse im zusätzlichen 'Sender:'-Header stehen.

Message-ID (MID): Die Message-ID (zu finden im Header 'Message-ID') dient der eineindeutigen Identifizierung von Artikeln (insbesondere im Usenet). Das heißt, im Zweifelsfall werden zwei Artikel mit identischer Message-ID als ein- und derselbe angenommen. Das bedeutet natürlich auch, daß die MID im Header eines Artikels eineindeutig generiert werden muß. Dazu wird in RfC1036 2.1.5 folgendes Format definiert: "<localpart@FQDN>". Der 'Localpart' ist dabei weitgehend der generierenden Software überlassen, diese muß nur dafür sorgen, daß die MID im Geltungsbereich des FQDN eineindeutig ist. Der FQDN (Fully Qualified Domain Name) ist üblicherweise der Servername (z.B. in der Form '@news.provider.tld'), auf dem die Nachricht eingeliefert wird und wo dann die MID auch generiert wird. Werden von mehr als einer Instanz MIDs mit demselben FQDN generiert, so müssen diese untereinander abgestimmt sein, um Kollisionen zu vermeiden. Das einfachste ist in einem solchen Fall, die FQDN durch eindeutige Namen zu erweitern, also z.B. in der Form '@user1.provider.tld'. Dies sollte natürlich immer nur mit dem Einverständnis des Inhabers der Namensrechte dieser Domain geschehen. In allen anderen Fällen sollte man den Server die MIDs generieren lassen, also auf selbstgenerierte Message-IDs verzichten.
Nun stellt sich vielleicht die Frage, was denn überhaupt durch mehrfach auftretende identische MIDs geschehen kann. Nun, eigentlich nichts schlimmes, nur wird der zweite und nachfolgende Artikel mit derselben MID nicht, oder nur teilweise verbreitet, mit der Folge, daß u.U. niemand den Artikel zu lesen bekommt. Um zu verstehen, warum das so ist, gilt es das Verteilungsprinzip im Usenet zu verstehen.
Artikel werden im Usenet nach dem 'Floodfill'-Prinzip verteilt, d.h. es werden keine festgelegten Verteilungswege benutzt, sondern ein Artikel wird solange in alle Richtungen verteilt, bis auf jedem Verteilungsweg ein Newsserver auftritt, der den Artikel bereits hat. Genauer gesagt bietet jeder Newsserver alle eingehenden Artikel (ob von einem anderen Server oder direkt bei ihm eingeliefert) an alle Newsserver an, mit denen ein Austauschabkommen (Peering Agreement) besteht. Bekommt ein Server einen Artikel angeboten, dessen MID er noch nicht kennt (Vergleich der 'History'), und dessen Datum nicht älter ist als der älteste Eintrag der MID-Tabelle (History) so wird er ihn annehmen und in die jeweiligen Newsgroups einfügen. Kennt der Server die Message-ID aber schon, so nimmt er den Artikel nicht an und leitet ihn auch nicht weiter, da er schon beim ersten Empfang des Artikel (bzw. eines Artikels mit der MID) diesen weitergeleitet haben müßte.
Daraus ist konsequent zu schlußfolgern, daß ein Artikel, dessen MID mit der eines anderen übereinstimmt, auf den meisten Servern nicht sichtbar werden wird.
Besonders gravierend ist das Problem übrigens bei Software, die ungültige MIDs mit häufig auftretenden gleichen Merkmalen hat. Microsoft Internet Mail und News z.B. erzeugt gerne MIDs der Form: '<zahl$zahl@default>'. Setzt man nun voraus, daß sehr viele Personen diese Software einsetzen, so ist eine zufällig übereinstimmende MID evtl. gar nicht mehr so unwahrscheinlich. Speziell für dieses Problem gibt es die MSIN FAQ.

Textgestaltung

Man sollte bei der Textgestaltung natürlich darauf achten, daß man sich nicht selbst der Peinlichkeit preisgibt. Wer durchgängig GROSSSCHREIBT, der wird sich nicht unbedingt Freunde machen, da diese Schreibweise als SCHREIEN empfunden wird. Ebenso sollte man lieber vom Einsatz mutipler Satzzeichen, insbesondere Ausrufezeichen, Abstand nehmen!!!!!
Um nur ein beliebtes Zitat zu dem Thema zu nennen:
"Five exclamation marks, the sure sign of an insane mind."
(Terry Pratchett, Reaper Man)

Auch der Einsatz von allzu vielen Smileys kann bisweilen befremdlich wirken, besser an strategisch wichtigen Stellen einige einsetzen und dann am Ende des Artikels einen Hinweis auf den humoristischen Charakter (ein 'SCNR' reicht da meist) hinzufügen.

Es mag trivial erscheinen, auch die Rechtschreibung gehört zur Höflichkeit. Niemand erwartet immer fehlerfreie Beispiele ausgefeilter Grammatik zu lesen. Aber auch hier gilt, man sollte seine Artikel gut lesbar halten. Vollständige Vernachlässigung der Groß-/Kleinschreibung z.B. erschwert das schnelle Auffassen eines Textes ebenso stark, wie auch ein Verzicht auf Zeichensetzung. Wer will, daß seine Artikel gelesen werden, sollte dem Leser das Aufnehmen des Inhaltes erleichtern.

Plonk und Killfile

Ein Killfile (Liste zum Filtern von Artikel aufgrund bestimmter Merkmale) dient dazu unerwünschte Artikel gar nicht erst anzunehmen oder direkt nach Empfang zu löschen. Dies kann verwendet werden, um Spam auszufiltern (typische Merkmale wie "$$$" u.ä. im Subject) oder um die Artikel von ungeliebten Autoren auszufiltern.
Ein *Plonk* ist das Eintragen eines Autoren in dieses Killfile, auch die Mitteilung über die Eintragung fällt unter diese Bezeichnung.

"Plonken, zumindest das öffentliche, wird kontrovers diskutiert.
Die einen meinen - es gehe niemand etwas an, wer wen liest und wen nicht. Dazu sei öffentliches plonken oft der Ausdruck von Hilflosigkeit. Viele bestehen auch darauf, ohne Killfile auszukommen.

Die anderen sehen darin eine 'erz. Aktion'. Es gab sogar schon eine Usenet-Gruppe unter de.alt.killfiles. Auch werden immer mal wieder Killfiles ins Web gestellt.

Wenn es viele PLONKS hagelt, und die nicht (nur) von Newbies kommen, ist es ein Zeichen dafür, dass man etwas falsch gemacht hat. Auch sind viele PLONKS in einer Gruppe (auf einen Schreiber gemünzt) oft ein Versuch, einen lästigen Eindringling 'loszuwerden'." (R. Kopka)

Troll

Die Auslegung des Begriffes Troll unterliegt einer gewissen Unschärfe. So gibt es den gut konstruierten Troll, der eine gewisse satirische Qualität aufweist und lediglich Leute erregt, die nur verstärkt ihre mangelnde Sachkenntnis aufzeigen.
Dies ist aber heutzutage eher selten der Fall. Häufiger sind die Trolle der Art "Ihr seid alle dumm", "Ich mache was ich will", oder das oft gesichtete Beispiel eines Postings in eine (de.)alt.fan.{irgendwer} Gruppe mit Aussagen der Art "{Irgendwer} ist Mist/kann nicht schreiben/kann nicht singen/kann nicht was-auch-immer. Jeder der das anders sieht muß ein Idiot sein".
Bei alledem sollte man dennoch vorsichtig mit der Beurteilung sein, denn die Grenzen von reiner Meinungsäußerung zu Trolling sind unter Umständen schwer zu ziehen.

"1) Oft wird nicht nur der Artikel so bezeichnet sondern auch der Urheber. Meistens taucht der Troll als 'Neuer' oder 'Erstposter' in einer Gruppe auf.
2) /Grzimek-Mode on
Erfahrenere Netizens haben eine `Trollwarnleuchte' gut sichtbar an ihrem Monitor angebracht und reagieren sehr selten auf seine Erscheinung.
Grzimek-Mode off/" (R. Kopka)

Signaturen

Nochmal zur Verdeutlichung, eine korrekte Signatur wird durch "-- " eingeleitet, für Neunmalkluge sei klargemacht, daß es sich dabei um die Zeichen mit den ASCII-Werten 45, 45 und 32 handelt, nicht etwa irgendetwas, daß auf irgendwelchen Rechnern so ähnlich aussieht (und demzufolge weder in ASCII noch (im Falle der Bindestriche) in ISO-8859-1 definiert ist).

[Zum Seitenanfang]

Zum Haupttext