 |
 |
 |
|
||
|
|||||
|
|
|
|||
|
|||||
|
|
|
Fragen & Antworten1. Technische Fragen
2. Fehlermeldungen und technische Probleme
3. Gruppenangebot und -auswahl
4. Benutzer-Daten
5. Policy und Abuse
6. Allgemeine Informationen zum Service
1. Technische Fragen
Individuelle Anmeldung und Nutzung des Dienstes setzen voraus, dass Sie einer DFN-Mitgliedsorganisation angehören, die mit dem DFN einen entsprechenden Nutzungsvertrag abgeschlossen hat. Unter http://news.cis.dfn.de/ finden Sie in diesem Fall alle erforderlichen Informationen. Bitte lesen Sie sich unbedingt die "Regeln zur Benutzung" durch, damit Sie sich über die Policy (die "Spielregeln") des Services im Klaren sind. Die Informationen des DFN für Organisationen, die sich für diesen Dienst interessieren, finden Sie unter: http://www.dfn.de/dienstleistungen/dfnnetnews/
Wir bemühen uns, die Anfragen spätestens innerhalb des nächsten Werktages zu beantworten. Krankheit, Urlaub, Tagungen oder andere Personalengpässe können allerdings dazu führen, dass dies im Einzelfall auch mal etwas länger dauert. Eine Bestätigung für den Eingang des Requests bei uns sollte jedoch jeder sofort erhalten.
Nein. Sollten Sie derartige Effekte bemerken, so liegt dies in aller Regel an Leitungs- oder Gateway-Engpässen.
Ja, es dürfen mehrere Threads gleichzeitig geöffnet werden. Wir bitten, dies auf 4 gleichzeitige Verbindungen zu beschränken sowie das Connect-Intervall größer als 5 Minuten zu wählen, damit es nicht zu Beeinträchtigungen der anderen User kommt.
Es ist extrem unwahrscheinlich, dass ein bestimmter Artikel unseren Server nicht erreicht, denn je nach Newsgruppe wird die Newsversorgung von über 200 Peers gewährleistet. Allerdings wird bei uns das Programm "cleanfeed" eingesetzt, das als Filter gegen Spam und Binaries in Diskussionsgruppen fungiert. Jeder Artikel, der bei uns eintrifft, wird dieser Überprüfung unterzogen und ggf. vom Server entfernt. Unterschiede kann es ebenfalls geben, falls der Vergleichsserver keinerlei Cancels oder Supersedes ausführt. Cancel bzw. Supersedes befehlen dem Newssystem das Löschen bzw. das Überschreiben eines bestimmten Artikels. Führen Server diese Befehle nicht oder nur selektiv aus, ergeben sich Unterschiede im Artikelbestand. Details zur Behandlung von Cancels und Supersedes auf unserem Server finden sich unter #1.12 dieser FAQ.
Die Speicherung Ihrer Zugangsdaten im Computer erleichtert die Nutzung, stellt aber ein gewisses Sicherheitsrisiko dar, wenn andere Personen Zugang zu diesen Daten erhalten. Diese können dann in Ihrem Namen über unseren Server Newsartikel absetzen. Wir empfehlen deshalb, das Passwort nur dann im Rechner zu speichern, wenn Sie den Rechner alleine nutzen. Auf keinen Fall sollten Sie Ihre Daten auf öffentlichen Rechern speichern, z.B. in einem Internetcafe. Wichtig: Wenn Ihr Passwort in falsche Hände geraten sein könnte, z.B. durch Diebstahl, dann geben Sie uns so schnell wie möglich per E-Mail an "news@cis.dfn.de" Bescheid. Wir werden Ihnen dann neue Zugangsdaten zuteilen.
Dieses Angebot finden wir sehr toll und würden es ggf. auch annehmen.
Allerdings müssen wir auf ein paar Randbedingungen hinweisen:
Die Software des Servers News.CIS.DFN.DE ist so modifiziert, dass bestimmte Headerzeilen zusätzlichen Überprüfungen unterzogen werden. Dieses gilt auch für die "Path:"-Zeile. Grundsätzlich wird dieser Header in jedem Fall vom Server neu generiert - auch dann, wenn der Artikel bereits mit "Path:"-Zeile eingeliefert wurde (und unabhängig davon, was vom Client für diesen Eintrag übermittelt wurde). Von diesem Verhalten gibt es Ausnahmen:
Normalerweise ist es für Benutzer von News.CIS.DFN.DE nicht möglich, Steuernachrichten (Control-Messages), die das Gruppenmanagement betreffen (*), über diesen Server zu verschicken. (*) Das sind newgroup-, rmgroup- oder checkgroups-Messages Da jedoch immer wieder mal eine entsprechende Anfrage von berechtigten Personen (z.B. Hierarchie-Moderatoren) kommt, haben wir in unser Usermanagement eingebaut, dass die Möglichkeit, Control-Messages zu verschicken, pro Benutzer freigeschaltet werden kann, wobei der Default auf "NO" steht. Wer jedoch möchte und dies entsprechend begründen kann, hat die Option, sich dieses Feature von uns freigeben zu lassen - in diesem Fall bitte eine Mail an "news@cis.dfn.de" schicken und darlegen, warum die Freigabe erfolgen soll.
Das direkte Posten in moderierte Gruppen ist Benutzern unseres Servers normalerweise nicht möglich, da wir Postings mit "Approved" Header nicht annehmen. Diese Vorgehensweise ist jedoch pro Benutzer konfigurierbar. Wer möchte und dies entsprechend begründen kann, hat die Option, sich dieses Feature von uns freigeben zu lassen - in diesem Fall bitte eine Mail an "news@cis.dfn.de" schicken und darlegen, warum die Freigabe erfolgen soll. Ein Hinweis (URL), wo man ggf. nachlesen kann, dass der Anfragende tatsächlich der zuständige Moderator ist, wäre hilfreich - ebenso wie die Angabe der User-ID, unter der man bei uns registriert ist.
Der Server führt Cancels und Supersedes im Allgemeinen nicht aus. Ein Artikel auf unserem Server kann also weder durch einen Cancel gelöscht noch durch einen Supersedes überschrieben werden, was dazu führt, dass woanders durch Cancels gelöschte Artikel weiterhin bei uns vorhanden sind (Artikel wurden nicht gelöscht) resp. woanders durch Supersedes überschriebene Artikel mehrfach bei uns vorliegen (Artikelversionen wurden nicht gegeneinander ersetzt). Der Server beachtet jedoch die Header "Cancel-Lock:" und "Cancel-Key:", die eine verifizierbare Verbindung zwischen einem Cancel/Supersedes und dem dazugehörigen Artikel herstellen, ohne eine Profilbildung zu ermöglichen. 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. Derweiteren führen wir eine Whitelist von Absendern; diese enthält Despammer ("professionelle" Spam-Canceller), damit deren erwünschte Spamcancels und NoCeM Notices ausgeführt werden, sowie Versender von regelmäßigen Informationstexten, so dass mit Supersedes ältere Versionen überschrieben werden können.
Ja, der Dienst kann optional mit SSL-Verschlüsselung (NNTPS / NNTP über SSL) genutzt werden, wobei nicht nur die Authentifizierungsphase, sondern die komplette Verbindung verschlüsselt ist. Hierfür ist im Newsreader als Port "563" (der Standard-NNTPS-Port) einzutragen, der Servername bleibt "News.CIS.DFN.DE". Bitte beachten Sie die Anleitung Ihres Newsreaders, ob Sie ggf. noch weitere Einstellungen ändern müssen, um SSL-Verschlüsselung nutzen zu können. 2. Fehlermeldungen und technische Probleme
Richten Sie Ihre Anfrage an "news@cis.dfn.de". Sie erleichtern uns die Arbeit, wenn Sie uns außerdem Ihre Usernummer mitteilen. Wie und wo Sie diese ablesen können, erfahren Sie im Abschnitt 4 (Benutzer-Daten). Sollten Sie schon Probleme mit dem Zugang als solchem haben, so wäre es hilfreich, wenn Sie die unter 2.3 beschriebenen Überprüfungen vornehmen und uns das Ergebnis (Fehlermeldungen u.ä.) mitteilen würden.
Das kann natürlich im Einzelfall mal geschehen sein - fast immer
jedoch liegt das an technischen Problemen irgendwo auf dem Wege von
Ihnen zu uns, die nach kurzer Zeit wieder behoben sind. Warten Sie
daher bitte einige Zeit ab, bevor Sie uns wegen eines derartigen
Fehlers anschreiben und überprüfen Sie dann erneut, ob das Problem
immer noch auftritt. Falls ja, so beschreiben Sie es bitte in Ihrer
Mail möglichst genau. Vorhersehbare und geplante Unterbrechungen des Dienstes geben wir in der Newsgruppe de.comm.provider.usenet bekannt, das Subject solcher Mitteilungen beginnt mit "[DNN]".
In fast allen Fällen liegt dies daran, dass Ihr Rechner durch eine
so genannte Firewall vom Internet abgeschirmt wird. Dies kann eine
zentrale Firewall Ihrer Organisation (Hochschule, Firma, ...) sein,
aber auch ein auf Ihrem eigenen Rechner installiertes Programm, das
sich z.B. als "Desktop Firewall" oder "Personal Firewall" bezeichnet.
Firewalls sind oftmals so konfiguriert, dass sie die Dienste Mail und
WWW transparent zur Verfügung stellen, NNTP (News) jedoch
abblocken.
a) Kommando "traceroute news.cis.dfn.de"
b) Kommando "telnet news.cis.dfn.de 119"
Der Befehl "traceroute" läuft anschließend ohne weitere Interaktion
ab. Bei "telnet 119" sind hingegen einige Benutzereingaben
erforderlich. Das sieht in etwa folgendermaßen aus (nur die letzten Zeilen sind dargestellt): [traceroute/tracert aufrufen]
Verfolgung der Route zu news.cis.dfn.de [130.133.4.13] Über maximal 30 Abschnitte: ... ... 7 106 ms 105 ms 109 ms usa.zedat.fu-berlin.de [160.45.252.6] 8 111 ms 110 ms 111 ms news.cis.dfn.de [130.133.4.13] Route-Verfolgung beendet. [telnet aufrufen]
200 The server welcomes test.fu-berlin.de (160.45.0.23). Authorization required for reading and posting. authinfo simple musterfrau ######## 281 Authorization accepted. (UID=1234567) quit 205 .
a) und b) funktionieren nicht
a) funktioniert, aber b) nicht
a) und b) funktionieren Hinweis: Der oben verwendete NNTP-Befehl "authinfo simple" gehört nicht zum Standardbefehlssatz und ist daher bei anderen Newsservern ggf. nicht einsetzbar.
In der bei uns aktiven Version des Newsreader-Daemons "nnrpd" ist eine spezielle Überprüfung eingebaut: Defaultmäßig darf jeder User maximal n Postings pro Tag über uns absetzen ("n" ist derzeit auf 100 festgesetzt). Wer versucht, mehr Artikel zu posten, erhält die Fehlermeldung "Daily posting limit (n articles) exceeded."
Diese Maßnahme ist dazu gedacht, Spam über uns zu verhindern.
Auf unserem Server ist das Programm "cleanfeed" installiert. Bitte konfigurieren Sie Ihren Newsreader so, dass Ihre Postings im Text- und nicht im HTML-Modus erstellt werden. Anschließend sollten Sie ohne Probleme über unseren Newsserver posten können. Die geschilderte Überprüfung erfolgt ausschließlich für _bei uns_ gepostete Artikel. Postings, die wir über die Peerings mit anderen Newsservern erhalten, bleiben davon unberührt. Ausgenommen vom HTML-Check sind derzeit die Hierarchien alt.*, microsoft.* und netscape.*.
Diese Fehlermeldung lautet vollständig: Wer möchte und dies entsprechend begründen kann, hat die Option, sich dieses Feature von uns freigeben zu lassen - in diesem Fall bitte eine Mail an "news@cis.dfn.de" schicken und darlegen, warum die Freigabe erfolgen soll. Wir geben dieses Feature in aller Regel jedoch nur für Moderatoren von Newsgruppen frei, so dass in der Mail an uns darauf hingewiesen werden sollte. Ein Hinweis (URL), wo man ggf. nachlesen kann, dass der Anfragende tatsächlich der zuständige Moderator ist, wäre ebenfalls hilfreich - ebenso wie die Angabe der User-ID, unter der man bei uns registriert ist.
Auf unserem Server ist das Programm "cleanfeed" installiert. Wird ihr Artikel mit dem Hinweis "EMP" (Excessive Multi-Posting) abgelehnt, so geschieht dies, weil während eines bestimmten Zeitraums schon mehrere gleichlautende (oder sehr ähnliche) Artikel bei uns eingeliefert wurden - von Ihnen oder auch von anderen Usern. Letzteres kann passieren, wenn Sie einen Provider benutzen, der dynamische IP-Nummern vergibt und Ihnen zufällig die IP-Nummer eines Kunden zugewiesen wurde, der kurz vorher ebenfalls über uns gepostet hat. Auftreten kann es ebenfalls bei Postings, die zufällig gleichlautend sind (z.B. Testpostings), aber natürlich auch beim zufälligen Zusammentreffen mehrerer Umstände, die spezifisch für Ihren konkreten Fall sind. In den meisten Fällen wird eine leichte Modifikation des Textes, den Sie posten wollen, Abhilfe schaffen - ggf. auch die Änderung des Subjects.
Die genaue Fehlermeldung lautet "441 Line n too long", wobei "n" die beanstandete Zeile angibt. Allerdings ist dabei die entsprechende Zeile im kompletten Artikel (inklusive des Headers) gemeint, die in diesem Fall gegen die laut Internet-Standard geltenden Längenbeschränkungen verstößt. In aller Regel ist dies die "References"-Zeile und das Problem tritt bei manchen Newsreadern auf, wenn man auf einen Artikel antwortet, der selber schon Bezug nimmt auf mehrere Vorgängerartikel. Abhilfe schaffen hier nur die Verwendung eines Newsreaders, der sich an die Standards hält, oder das manuelle Editieren der beanstandeten Header-Zeile.
Nun, eigentlich sollte diese Fehlermeldung selbsterklärend sein. Der volle Wortlaut ist "441 437 YOUR SYSTEM DATE IS WRONG! Too old -- DATUM", wobei bei "DATUM" das angegeben ist, was uns Ihr Newsreader als Erstellungsdatum des Artikels übermittelt hat. Liegt dieses Datum länger als 7 Tage zurück, so wird der Artikel abgelehnt. Bitte überprüfen Sie unbedingt die Systemzeit Ihres Rechners und setzen diese auf den korrekten Wert.
Ihr Account wurde gesperrt. Dies kann unterschiedliche Ursachen haben, beruht jedoch meistens auf einem Verstoß gegen unsere Policy (siehe http://news.cis.dfn.de/rules.html). Nehmen Sie daher bitte ggf. per Mail Kontakt mit uns (news@cis.dfn.de) auf, wobei es hilfreich ist, wenn Sie uns Ihre Usernummer mitteilen oder die E-Mail-Adresse, unter der Ihre Anmeldung bei uns erfolgte.
Sie haben mit großer Wahrscheinlichkeit in eine so genannte "moderierte" Gruppe gepostet. Moderierte Gruppen erkennt man u.a. daran, dass die Kurzbeschreibung der Gruppe mit dem Hinweis "(Moderated)" endet. Wie Sie sich eine solche Kurzbeschreibung ansehen können, entnehmen Sie bitte der Dokumentation Ihres Newsreader-Programms. Alternativ können Sie in der Liste unter ftp://ftp.fu-berlin.de/doc/news/fu-berlin/newsgroups nachsehen. Nachrichten in moderierte Gruppen werden nicht sofort auf dem Newsserver zur Verfügung gestellt, sondern per Mail an die Adresse des Moderators dieser Gruppe geschickt. Dieser muss sie dann von Hand sichten und ggf. in die Gruppe stellen. Je nach Moderator dauert dies wenige Minuten bis etliche Tage. Erscheint Ihr Posting gar nicht, obwohl offensichtlich später eingereichte Nachrichten schon vom Moderator in die Gruppe weitergeleitet wurden, so kann das daran liegen, dass Sie eine ungültige E-Mail-Adresse in der "From:"-Zeile verwenden. Viele Moderatoren benutzen eine Reihe von Scripts und Programmen, um sich ihre Arbeit zu erleichtern. Dazu gehört auch, dass auf dem für die Annahme der Artikel zuständigen Mailserver geprüft wird, ob die Absendeadresse des Autors gültig ist. Falls nicht, wird die Nachricht abgelehnt und gar nicht erst an den Moderator weitergeleitet. Bitte verwenden Sie also eine gültige E-Mail-Adresse, wie ja auch in unserer Policy empfohlen.
Sie können nur Artikel canceln, die von Ihnen geschrieben und über unseren Server gepostet wurden. Erhalten Sie die oben genannte Meldung, haben Sie versucht, einen Artikel zu canceln, der nicht von Ihnen geschrieben wurde oder den Sie nicht über unseren Server gepostet haben. Im letztgenannten Fall canceln Sie den betreffenden Artikel bitte über den Server, über den Sie ihn auch gepostet haben.
Sie haben versucht, einen Artikel zu canceln, der unter einer anderen User-ID als der Ihren gepostet wurde. Sie dürfen nur Artikel canceln, die unter Ihrer eigenen User-ID gepostet wurden.
Wenn unser Server in sehr hoher Frequenz (viele Verbindungsaufbauten in kurzer Zeit) angesprochen wird, aktivieren sich automatische Sperrmechanismen für die entsprechende IP-Adresse. Bitte konfigurieren Sie Ihre Software in Einklang mit den Werten aus #1.4 unserer FAQ. Sollten Sie Ihre Software entsprechend konfiguriert haben, die oben genannte Fehlermeldung aber dennoch erhalten, setzen Sie sich bitte mit "news@cis.dfn.de" in Verbindung. Bitte nennen Sie in der Mail neben Ihrem Account-Namen auch das Datum und die Uhrzeit, zu der Sie die Meldung erhalten haben, sowie die in der Fehlermeldung ausgegebene IP-Adresse und die von Ihnen benutzte News-Software.
Diese Meldung erhalten Sie, wenn Sie (oder Ihre Software) zu viele falsche NNTP-Befehle an unseren Server geschickt haben. Dies umfasst Syntax- und Tippfehler, Nicht-NNTP-Befehle und Befehle, die besonderer Berechtigung bedürfen. Bitte beachten Sie: Bevor Sie sich an unserem Server authentifiziert haben, gelten alle Befehle (auch syntaktisch korrekte und solche, zu denen Sie nach Authentifizierung berechtigt wären) als falsch (Ausnahmen: Die Befehle "help" und "list"). Sollten Sie also die oben genannte Meldung von unserem Server erhalten, prüfen Sie bitte als erstes nach, ob Sie sich korrekt authentifiziert haben. Sollte das Problem auftreten, obwohl Sie sicher sind, sich korrekt authentifiziert zu haben, wenden Sie sich bitte unter Angabe von Account-Namen, Datum und Uhrzeit der Fehlermeldung sowie der von Ihnen benutzten News-Software per Mail an "news@cis.dfn.de".
Sie können nur Artikel superseden, die von Ihnen geschrieben und über unseren Server gepostet wurden. Erhalten Sie die oben genannte Meldung, haben Sie versucht, einen Artikel zu superseden, der nicht von Ihnen geschrieben wurde oder den Sie nicht über unseren Server gepostet haben. Im letztgenannten Fall superseden Sie den betreffenden Artikel bitte über den Server, über den Sie ihn auch gepostet haben.
Sie haben versucht, einen Artikel zu superseden, der unter einer anderen User-ID als der Ihren gepostet wurde. Sie dürfen nur Artikel superseden, die unter Ihrer eigenen User-ID gepostet wurden. 3. Gruppenangebot und -auswahl
Prinzipiell werden ausschließlich Diskussionsgruppen geführt, die nach den Konventionen der jeweiligen Hierarchie eingerichtet wurden. Nicht geführt werden insbesondere Binary-Gruppen sowie einige Subhierarchien von alt.* Welche Hierarchien generell aufliegen, können Sie dem URL http://news.cis.dfn.de/hierarchies.html entnehmen. Fortgeschrittene Benutzer, die sich mit der Arbeitsweise von Newsservern auskennen und sich für das "active"- oder "newsgroups"-File von News.CIS.DFN.DE interessieren, können diese Dateien unter ftp://ftp.fu-berlin.de/doc/news/fu-berlin/active bzw. ftp://ftp.fu-berlin.de/doc/news/fu-berlin/newsgroups abrufen. Die Aktualisierung der Dateien auf dem FTP-Server erfolgt einmal am Tag.
Je nach Hierarchie stehen die Artikel zwischen 40 und 200 Tage zur Verfügung. Genauere Informationen sind in der Liste der bei uns verfügbaren Hierarchien enthalten, die Sie unter http://news.cis.dfn.de/hierarchies.html abrufen können. Aus technischen und administrativen Gründen können wir die Haltezeiten nur pro Hierarchie konfigurieren, nicht jedoch für einzelne Gruppen.
Auf eine Newsgruppenzahl in der Größenordnung von 60.000 bis 80.000 kommen normalerweise nur ungepflegte Newsserver. Dies sind Server, auf denen jede Newsgruppe eingerichtet wird, für die irgendwann mal ein Artikel erscheint - selbst dann, wenn diese "neue" Gruppe nur aus einem Tippfehler heraus resultiert. Auf solchen Servern werden meistens auch keinerlei Gruppen gelöscht, was u.a. dazu führt, dass nach Umbenennungen oder Gruppenaufteilungen die alten neben den neuen Gruppen existieren. Unser Bestreben ist es, einen gut gewarteten Server bereitzustellen. Wir richten neue Gruppen nur ein, wenn sie nach den in der jeweiligen Hierarchie üblichen Gepflogenheiten ins Leben gerufen und mit entsprechenden Mechanismen "announced" wurden. Umgekehrt werden obsolete Gruppen auch nach dem zugehörigen administrativen Hinweis gelöscht. Diese Verfahren sorgt dafür, dass die Gruppenlisten der einzelnen Hierarchien dem aktuellen Stand entsprechen und keine "illegalen" Gruppen oder Karteileichen geführt werden. Dieses Verfahren ist aufwendiger, als einfach "alles" einzurichten, und man kommt auch nicht annähernd in die genannten Größenordnungen, aber für die Benutzer des Services ist ein gewarteter Newsserver von viel größerem Wert.
Bitte richten Sie die entsprechende Anfrage an "news@cis.dfn.de". Die auf dem Server geführten Hierarchien (ohne alt.* und free.*) stehen - mit Ausnahme der Binary-Gruppen - komplett zur Verfügung. Bevor Sie wegen der Aufnahme einer Newsgruppe in einer dieser Hierarchien nachfragen, stellen Sie bitte sicher, dass Sie bzw. Ihr Newsreader tatsächlich über eine aktuelle und vollständige Newsgruppenliste verfügen, d.h. veranlassen Sie zunächst eine Synchronisation mit unserem Server. Die Hierarchien alt.* und free.* enthalten sehr viele Gruppen, die mittlerweile nicht mehr gelesen werden. Daher werden die meisten alt- und free-Gruppen auf dem Server nur auf Nachfrage von Benutzern eingerichtet.
Nicht geführt werden u.a. die folgenden Subhierarchien:
Das ist möglich, hängt aber von der jeweiligen Hierarchie ab. Da die Einführung einer neuen Hierarchie sehr viel mehr Arbeit macht als die Neuaufnahme von Gruppen in bereits bestehenden Hierarchien, kann es außerdem einige Zeit dauern, bis eine solche Hierarchie stabil zur Verfügung gestellt werden kann. Es beschleunigt die Aufnahme neuer Hierarchien, wenn folgende Informationen bereits vom Anfragenden zur Verfügung gestellt werden:
Nein, das können wir nicht so einfach.
In der Hierarchie de.* gibt es wie in vielen anderen Hierarchien
gewisse Regeln, nach denen eine Gruppeneinrichtung erfolgt. Wie das
genau abläuft, wird regelmäßig gepostet:
Die Gruppe de.alt.0d wird bei uns mit dem Flag "n" geführt. Dies bedeutet "no posting", so dass die Gruppe bei uns de facto "read only" zur Verfügung steht. Da in de.alt.0d ohnehin alle Artikel automatisch gecancelt werden, spielt das im Endeffekt auch keine Rolle. Wir haben die Gruppe bei uns in dieser Weise konfiguriert, um uns die Rückfragen zu ersparen, in denen unerfahrene Nutzer wissen möchten, warum ihr Posting verschwunden ist oder wie andere Leute dazu kämen, ihr Posting zu canceln. Die Kennzeichnung der Gruppe als "read only" bewirkt bei der von uns eingesetzten Software standardmäßig, dass auch kein Followup-To: dorthin gesetzt werden kann. Im Falle von de.alt.0d ist das ein von uns durchaus gewünschter Nebeneffekt, da ein Followup-To auf diese Gruppe nur das Ziel haben kann, unerfahrene Benutzer aufs Glatteis zu führen. Dies ist ein im Sinne der Netiquette zumindest fragwürdiges Verhalten, zumal es geeignetere Gruppen gibt, in die man tatsächlichen oder vermeintlichen Unsinn umlenken kann (wie z.B. de.alt.dummschwatz oder de.alt.gruppenkasper). Für die Gruppe alt.dev.null gilt Ähnliches. Hier werden zwar die Postings nicht automatisch gecancelt, aber laut Charta soll die Moderations-Adresse auf "/dev/null" zeigen - das ist der "Mülleimer" von Unix-Systemen. Für unerfahrene Benutzer ist dies ebenfalls nicht zu durchschauen.
Die Verteilung von News zwischen großen Servern erfolgt über den Austausch kompletter (Sub-) Hierarchien. Die entsprechenden Konfigurationen reichen nicht hinunter bis zu einzelnen Newsgruppen. So steht bei allen unseren Peers in der Subskriptionsliste für uns: alt.*,!alt.binaries.* (lies: schicke alle Artikel in alt.*, aber keine, die in alt.binaries.* gepostet wurden). Für die Einführung einer einzelnen Gruppe "alt.binaries.irgendwas" müssten wir die Administratoren aller Peers (und das sind zwischen 200 und 300!) anschreiben und sie bitten, die Subskriptionsliste entsprechend zu ergänzen. Das ist ein Aufwand, den wir nicht leisten können und der auch nicht gerechtfertigt ist - immerhin ist die Gruppe ja offensichtlich falsch eingeordnet und unterläuft damit den Sinn der Subhierarchie alt.binaries.
Flame-Gruppen sind dazu da, um Flame-Wars aus anderen Gruppen dorthin umzuleiten und um sich an geeigneter Stelle "Luft zu machen". Um diesen Zweck zu erfüllen, genügt aber eine Flame-Gruppe pro Hierarchie (im Allgemeinen "hierarchie.flame"), so dass wir keine Untergruppen führen.
In Zusammenarbeit mit dem FIDO-Netz haben wir eine Liste der Gruppen aufgestellt, die tatsächlich noch über ein Gateway zwischen Usenet und FIDO-Netz ausgetauscht werden. Die von Ihnen vermissten Gruppen gehören mit großer Sicherheit nicht dazu. Nähere Informationen dazu finden Sie unter ftp://ftp.fu-berlin.de/doc/news/fido.ger/ Es gibt allerdings Newsadministratoren, die sich nicht um die Wünsche des Fido-Netzes kümmern und auch Gruppen auf ihrem Server führen, für die überhaupt kein Gateway mehr existiert. In diesen Gruppen finden sich dann folgerichtig nur Artikel aus dem Usenet, jedoch keine aus dem Fido-Bereich.
clari.* ist ein kommerzielles Angebot der Firma ClariNet, das nur an zahlende Kunden dieser Firma weitergegeben werden darf.
Die Gruppe control.cancel, eine Pseudo-Newsgruppe, in die das Newssystem Cancel-Nachrichten einsortiert, ist auf unserem Newsserver vorhanden, sie wird aber in der Liste der Newsgruppen und in der Liste der Gruppenbeschreibungen automatisch ausgeblendet. Die Gruppe kann aber ganz normal betreten und abgerufen werden. Für User mit Nutzerzulassung (Username und Passwort) ist es zudem individuell pro Nutzer schaltbar, die Gruppe in die Listen einblenden zu lassen. Wenden Sie sich dazu bitte per E-Mail an "news@cis.dfn.de". 4. Benutzer-Daten
Die Daten unserer User werden nicht an Dritte weitergegeben - weder komplett noch im Einzelfall. Davon ausgenommen sind Daten, die aufgrund eines richterlichen Beschlusses den Ermittlungsbehörden zur Verfügung gestellt werden müssen. Die Daten werden auch von uns selber nicht für Werbezwecke, Umfragen o.ä. verwendet. Statistiken werden zur Zeit nicht erstellt. Sollte das in Zukunft der Fall sein, so werden nur anonymisierte Daten verwendet werden.
Bitte melden Sie sich nicht einfach neu an. Sollten Sie Ihre Zugangsdaten für den Newsserver vergessen haben, können Sie sich diese jederzeit über ein Online-Formular an Ihre bei uns hinterlegte E-Mail-Adresse schicken lassen: https://news.cis.dfn.de/remail.html
Sie können alternativ auch eine formlose Mail an "dfnnetnews@cis.dfn.de"
schreiben und um Neuzusendung Ihrer Zugangsdaten bitten. Sie
erhalten diese dann von uns per E-Mail an die E-Mail-Adresse, mit
der Sie sich bei uns registriert haben bzw. an die uns von Ihnen
zuletzt als gültig mitgeteilte Adresse (siehe auch
#4.7 unserer FAQ). Bitte haben Sie Verständnis dafür, dass wir in Ihrem eigenen Interesse keine Zugangsdaten "auf Zuruf" an E-Mail-Adressen versenden, bei denen wir nicht nachvollziehen können, dass sie wirklich mit dem betreffenden Account in Verbindung stehen.
Es gibt verschiedene Möglichkeiten:
Ja. Der FQDN setzt sich zusammen aus der Zeichenfolge "ID-", der
User-ID (Usernummer) und der Subdomain "user.dfncis.de":
ID-USERNUMMER.user.dfncis.de
Dabei ist "USERNUMMER" Ihre persönliche User-ID oder Benutzernummer
bei uns. Für den User mit der ID "1234567" lautet der FQDN
also "ID-1234567.user.dfncis.de". Hinweis: Alle Subdomains, die wir früher für die Erzeugung der User-FQDNs benannt und erlaubt haben (wie z.B. user.uni-berlin.de), bleiben gültig und dürfen weiterhin benutzt werden.
Ja, aber ausschließlich zum Generieren der Message-ID.
Das ist zur Zeit leider nur mit relativ hohem Aufwand möglich.
Bitte achten Sie darauf, dass wir immer eine gültige E-Mail-Adresse
von Ihnen haben, unter der wir Sie erreichen können.
Sie müssen die E-Mail-Adresse, die Sie uns als Kontaktadresse
nennen, nicht zum Posten in den News verwenden. Die Adresse dient
vornehmlich der Verifikation der Einrichtungszugehörigkeit, der
Zusendung von Zugangsdaten (siehe auch #4.2 unserer FAQ) und
der Kontaktaufnahme bei Nachfragen oder Problemen.
Sollte sich Ihre E-Mail-Adresse also gegenüber der Anmeldung
ändern, schreiben Sie uns bitte eine formlose Mail an
"dfnnetnews@cis.dfn.de", in der Sie uns Ihre neue Adresse mitteilen
(sofern möglich, bitte bevor die alte Adresse ungültig wird).
Bitte nennen Sie uns in Ihrer Mail zur Erleichterung der Zuordnung
auch Ihren vollen Namen sowie Ihren Usernamen und/oder Ihre User-ID
bei uns. Wir werden die neue E-Mail-Adresse dann entsprechend
vermerken. Bitte beachten Sie jedoch, dass wir ausschließlich E-Mail-Adressen aus Ihrer Einrichtung akzeptieren können. Sie können also keine Adresse bei Ihrem privaten Zugangsanbieter oder einem Freemailer eintragen lassen. 5. Policy und Abuse
Die Erfahrung hat leider gezeigt, dass ein völlig offener Newsserver verstärkt genutzt wird, um Missbrauch zu treiben. Wird das Abuse-Handling nicht von der teilnehmenden Organisation, sondern vom Team des DFNNetNews-Dienstes übernommen, so ist eine Validierung erforderlich, damit Kerndaten des Benutzers vorliegen, die bei der Verfolgung von Abuse-Fällen herangezogen werden können. Außerdem ist es so möglich, bei Missbrauch den Zugang individuell zu sperren.
Ein solches Verhalten würden wir sehr bedauern, da es natürlich die
Bereitstellung des Dienstes gefährdet. Bemerken wir policy-widriges Verhalten oder werden durch Beschwerden darauf aufmerksam gemacht, so sperren wir den betreffenden Account - in aller Regel ohne Rückfrage bzw. Information des Inhabers.
Wir empfehlen, eine spezielle Mail-Adresse nur für die Verwendung im Usenet einzurichten und diese mit passenden Filtermechanismen zu schützen. Damit wird Ihr reguläres Postfach nicht gestört, Sie können aber dennoch Antworten per Mail auf Ihre Usenet-Artikel erhalten. Eine andere Möglichkeit stellt die Benutzung der Top Level Domain ".invalid" (siehe RFC 2606) dar. Die Top Level Domain ".invalid" ist dazu gedacht, offensichtlich ungültige Adressen zu konstruieren, wie zum Beispiel "invalid@invalid.invalid". Solche Adressen belasten keine bestehenden oder fremden Namensräume und sind zudem für Mensch und Maschine eindeutig als ungültig zu erkennen.
Es fällt nicht unter "kommerzielle Nutzung" im Sinne unserer Policy, wenn der Newszugang von der Firma oder Arbeitsstelle aus genutzt wird. Selbst das Antworten auf gezielte Fragen zu Firmenprodukten ist zulässig, sofern dies als "Support" im landläufigen Sinne und nicht als Werbung erfolgt. Nicht erlaubt sind reine Werbe-Postings.
Das kommt auf die Art des Regelverstoßes an:
Ja, sofern dies technisch nicht anders zu lösen ist, was z.B. bei eigenständigen Newsservern oder Pseudo-Servern wie Hamster oder leafnode der Fall sein kann. Ein solches Vorgehen darf jedoch nicht dazu führen, dass unkontrolliert beliebige Personen den Dienst nutzen können, ferner dürfen keine Gateways zu protokollfremden Diensten wie WWW geschaffen werden. Auch bei einer solchen Konstruktion müssen in jedem Fall die Nutzungsregeln eingehalten werden.
HINWEIS:
Bitte stellen Sie sicher, dass Ihr Server nicht weltweit oder für einen unbestimmten Personenkreis geöffnet ist. Es gab bereits mehrere Fälle, in denen auf diese Weise trotz dynamischer IP-Adresse und relativ kurzer Online-Zeiten erheblicher Missbrauch (Fremdcancel, Spam) über den Account eines ahnungslosen Nutzers getrieben wurde.
Nein. Wer einen solchen Dienst anbieten möchte und dies über einen lokalen Newsserver realisiert, kann sich allerdings an uns wenden, um ggf. ein Peering zu vereinbaren. 6. Allgemeine Informationen zum Service
DFNNetNews ist ein Dienst, der vom DFN gegen Entgelt angeboten wird. Die Informationen des DFN für Organisationen, die sich für diesen Dienst interessieren, finden Sie unter: http://www.dfn.de/dienstleistungen/dfnnetnews/ Der Server wird betrieben von der Zentraleinrichtung für
Datenverarbeitung (ZEDAT), dem Hochschulrechenzentrum der Freien
Universität Berlin.
Wir haben einige Daten zu Hard- und Software des Newsservers unter dem URL http://news.cis.dfn.de/server.html zusammengestellt. Stand: 2012-12-14 |
|
||||||||||||||||||||||||||
|
|
|
|
|
||||||||||||||||||||||||||
