+------------------------------------------------------------+ | | | ka.* ist eine geschlossene und zentralistische Hierarchie. | | | +------------------------------------------------------------+ Was heisst das? =============== ka.* wird nicht auf den "Newsbackbones" einfach so verteilt, sondern die Peerings gehen zentralistisch von Karlsruhe aus und die angebundenen Sites werden in der Liste der ka-Sites erfasst. Entsprechend ist ka.* im offiziellen control.ctl-File (ftp://ftp.isc.org/usenet/CONFIG/control.ctl) auch als "*PRIVATE*" aufgefuehrt. Wo kann ich ka.* herbekommen? ============================= Derzeit ist ein Bezug von ka.* von folgenden Servern moeglich: * news.karlsruhe.org (Kontakt: usenetATkarlsruheDOTorg) * news.akk.org (Kontakt: usenetATakkDOTorg) * news.inka.de (Kontakt: usenetATinkaDOTde) * news.sub.net (Kontakt: newsadmATsubDOTnet) Der oberste Server ist die ka.*-Archivsite und fuehrt nur ka.*, die anderen fuehren auch noch andere Hierarchien. Was ist bei einem Peering zu beachten? ====================================== * nur lokal erzeugte Artikel zum ka.*-Peerpartner senden Dies kann z.B. bei INN erreicht werden, indem man die Omyhost- Option zum entsprechenden ka.*-Feed in der newsfeeds(5)-Datei einsetzt. "myhost" muss an der Stelle durch den im X-Trace- Header eingesetzten Hostnamen ersetzt werden. Sollen zum gleichen Peer neben ka.* gesandt werden, empfiehlt es sich, daraus zwei Eintraege mit gleichem Feedbezeichner in der newsfeeds(5) zu machen: Einen fuer ka.* mit Omyhost und einen ohne Omyhost fuer die anderen Hierarchien. Das geht natuerlich nur, wenn ein funnel-innfeed eingesetzt wird, bei innxmit-Feeds und Feeds mit Batchfile muessen verschiedene Feedbezeichner gewaehlt werden. Alternativ koennen auch entweder bei allen anderen Peers verhindert werden, dass ka.*-Artikel empfangen werden (durch patterns: "*,@ka.*" in der incoming.conf(5)) oder beim ka.*-Feed die Pfade aller anderen Peers als Aliase aufgefuehrt werden. Letztere Methode ist aber aufwaendig (muss bei jeder Peeringaenderung angefasst werden) und unzuverlaessig (wenn ein anderer Peer seinen Path-Namen unbemerkt aendert, packt sie nicht mehr). Bei anderer Server-Software sollten aequivalente Moeglichkeiten existieren, die Feed-Optionen entsprechend zu setzen. * keine ka.*-Artikel an andere Peers weitergeben Auch wenn ein andere Peer ebenfalls ka.* fuehrt, so ist es nicht erwuenscht, ka.*-Artikel direkt mit diesem austauschen. Folglich muessen allen anderen Peers entsprechende Excludes zum Peering hinzugefuehrt werden (also wieder in INN- newsfeeds(5)-Nomenklatur: *,!ka.*,!control.*). Ein @ka.* ist nicht notwendig, da dies in anderen Hierarchien Luecken erzeugen koennte. Eleganter ist es, die zu feedenden Hierarchien konkret aufzuzaehlen und somit auf ein fuehrendes '*' gaenzlich zu verzichten, sondern stattdessen leer zu beginnen ("!*" am Patternanfang bzw. im ME-Pseudofeed). Bei letzter Vorgehensweise bietet sich der Einsatz von Variablen im newsfeeds(5)-File an, um gleichartige Feeds einfach konfigurieren zu koennen, genaueres steht in der manpage. Auch hier gilt fuer anderere Server-Software: Entsprechende Settings sind zu waehlen. * Benutzer auf die ka.*-Regeln hinweisen Die auf http://www.karlsruhe.org/ einsehbaren ka-Rules sind bindend (insbesondere was Spam, Crosspostings, eMail-Adressen, etc. angeht). Benutzer sollten auf Nachfrage oder - sollte eine solche bestehen - auf einer allgemeinen Informationswebseite darauf hingewiesen werden. Einige Regeln lassen sich auch einfach in serverseitige Filter fassen (z.B. das Crossposting-Verbot). Wenn die Moeglichkeit besteht, derartige Filter einzusetzen, ist dies natuerlich willkommen. Insbesondere Crosspostings quer ueber die Marktgruppen verschiedener Regionalhierarchien sind ein Problem, das leicht mit derartigen Mitteln bekaempft werden kann. * Einen Eintrag in der ka.*-Sitelist vornehmen Naeheres dazu auf http://www.karlsruhe.org/ Warum eigentlich der ganze Aufwand? =================================== Primaer zur Spamvermeidung. Solange ka.* nicht nach aussen geroutet wird, ist die Existenz der Newsgruppen zumindest ausserhalb von Deutschland zum groessten Teil eher unbekannt. Folglich existieren die Gruppen auf den meisten Servern nicht, was wiederum zur Folge hat, dass sie auch nicht bespammt werden. Und die Spams, die Ausserhalb vom offiziellen ka.*-Bereich in ka.*-Gruppen gepostet werden, sollte dank inbound restrictions eigentlich nie den Bereich von ka.* erreichen. Ausserdem hat es fuer die Poster innerhalb von ka.* den Vorteil, dass die hier verwendeten eMail-Adressen nicht irgendwo in China oder Brasilien geharvestet und auf Spamlisten gesetzt werden. Natuerlich kann man das auch auf den an ka.*-beteiligten Servern nicht vermeiden, da diese potentiell zusammen mehrere Millionen Benutzer haben, aber die Wahrscheinlichkeit ist zumindest verringert. Wenn man andere deutsche Regionalhierarchien zum Vergleich betrachtet, sieht man, dass sich der Aufwand deutlich lohnt. Wie saehen Config-Eintraege fuer INN konkret aus? ================================================= Fuer ein Peering mit news.karlsruhe.org z.B. so (!* ist aufgrund des ME-Eintrags natuerlich doppelt gemoppelt): --- newsfeeds ------------------------------------------------ ME:!*:: ka/news.karlsruhe.org:\ !*,ka.*/!local\ Ap,Onews.example.com,Tm:INNFEED! otherpeer/otherpeer.example.org:\ de.*/!local\ Ap,Tm:INNFEED! INNFEED!:!*:Tc,Wnm*:/news/bin/startinnfeed -------------------------------------------------------------- --- incoming.conf -------------------------------------------- peer ka { hostname: "news.karlsruhe.org" patterns: "ka.*" } peer otherpeer { hostname: "foo-out.otherpeer.example.org" patterns: "*,!ka.*" } -------------------------------------------------------------- --- innfeed.conf --------------------------------------------- peer ka { ip-name: news.karlsruhe.org } peer otherpeer { ip-name: foo-in.otherpeer.example.org } -------------------------------------------------------------- --- filter_nnrpd.pl ------------------------------------------ sub filter_post { @newsgroups = split(/,/, $hdr{"Newsgroups"}); foreach (@newsgroups) { if (/^ka\./i) { $ka++; } else { $nka++; } } if ($ka && $nka) { if (!defined($hdr{"Followup-To"})) { $fka = 1; } else { @followupgroups = split(/,/, $hdr{"Followup-To"}); foreach (@followupgroups) { if (/^ka\./i) { $fka++; } } } if ($fka) { return "Keine Crosspostings nach ka.* (-> http://www.karlsruhe.org/)"; } } if ($ka > 3) { return "Zu viele Gruppen fuer ka.* (-> http://www.karlsruhe.org/)"; } return ""; } -------------------------------------------------------------- --- control.ctl ---------------------------------------------- ## KA (*PRIVATE* -- Karlsruhe, Germany) # Contact: usenet@karlsruhe.org # URL: http://www.karlsruhe.org/ # Key URL: http://www.karlsruhe.org/pubkey-news.karlsruhe.org.asc # Key fingerprint = DE 19 BB 25 76 19 81 17 F0 67 D2 23 E8 C8 7C 90 # For private use only, contact the above address for information. # *PGP* See comment at top of file. #newgroup:*:ka.*:drop #rmgroup:*:ka.*:drop # The following three lines are only for authorized ka.* sites. checkgroups:usenet@karlsruhe.org:ka.*:verify-usenet@karlsruhe.org newgroup:usenet@karlsruhe.org:ka.*:verify-usenet@karlsruhe.org rmgroup:usenet@karlsruhe.org:ka.*:verify-usenet@karlsruhe.org --------------------------------------------------------------